「うちもそろそろAI使わないと」——2026年、この言葉を経営会議で聞かなかった企業のほうが珍しいのではないでしょうか。
ただ、検索しても出てくるのは大企業の導入事例か、エンジニア向けのフレームワーク比較ばかり。3〜10人のチームが「今月中に何か動くものを作りたい」と思ったとき、最初に選ぶべき技術スタックの情報が意外と少ない。
この記事では、playpark（2人チーム）が実際にAI開発を始めた経験をもとに、スタック選定のチェックリストと判断フローを整理しました。
この記事で扱うこと
- AI活用の3段階（まず触る → 業務に使う → 仕組み化する）と進め方
- 小規模チーム向けスタック選定チェックリスト
- 「まずどこから始めるか」の判断フロー
- 避けたほうがいい初手と、その理由
AI活用の3段階——全部やる必要はない
まず全体像を押さえます。2026年現在、小規模チームのAI活用は大きく3段階に分けられます。
| 段階 | やること | 状態 | 技術難易度 |
|---|---|---|---|
| Stage 0: まず触る | ChatGPT / Claude / Gemini のアプリで遊ぶ | AIへの抵抗がなくなる | なし |
| Stage 1: 業務に使う | 日常業務にAIを組み込む | 「これAIでいけるな」と自然に浮かぶ | 低 |
| Stage 2: 仕組み化する | 繰り返し作業を自動化・システム化 | 処理量が増えて、さらに効率化したくなる | 低〜中 |
重要なのは、この順番をスキップしないこと。Stage 0を飛ばしていきなり「AI戦略」を考えても、AIに何ができるか肌感覚がないので判断を間違えます。
Stage 0: まず触る——遊ぶだけでいい
最初のステップは、業務と一切関係なくていい。ただAIで遊ぶ。
- 最高に笑える小噺を作らせてみる
- 恋人の誕生日プレゼントを一緒に考えてもらう
- 自分の趣味について延々と語り合う
- 旅行の計画を丸投げしてみる
- 料理のレシピを冷蔵庫の中身から考えてもらう
ChatGPT でも Claude でも Gemini でも、アプリを入れてとにかく触りまくる。ここで大事なのは「すごい」「微妙」「嘘ついた」「これは使える」という感覚を体で覚えること。
この段階で身につくのは:
- AIの得意不得意の肌感覚: 文章は得意、計算は苦手、最新情報は知らない
- プロンプトの勘所: こう聞くとうまくいく、こう聞くとズレる
- ハルシネーションの見分け方: もっともらしく嘘をつくパターンがわかる
- AIへの心理的ハードル消滅: 「使ってみようかな」が「使わない理由がない」に変わる
playpark の場合、最初の1週間はひたすらClaude と雑談していました。ブログのネタ出し、メールの言い回し相談、技術的な疑問の壁打ち。この「日常的にAIに話しかける習慣」が、次のステージへの自然な入口になります。
Stage 1: 業務に使う——「これAIでいけるな」が浮かぶ
Stage 0でAIを触り続けていると、仕事中にふと思うようになります。「これ、AIに頼めばよくない？」
この感覚が自然に浮かぶようになったら、Stage 1です。
やることはシンプル
- 普段の業務で「手作業で時間がかかっている」タスクを1つ選ぶ
- ChatGPT / Claude のアプリにコピペして、やらせてみる
- Before/Afterの時間を測る
最初はアプリへの手動コピペで構いません。この段階のゴールは「AIで業務が楽になる体験」を積むこと。
実例: playpark の Stage 1
playpark では最初に「営業メールの下書き生成」をAIに任せました。リード企業の情報をClaude に貼り付けて「この会社への営業メールを書いて」と頼む。手作業15分が2分に。
次に「議事録の要約」。会議の録音テキストを貼り付けて「要点を5つにまとめて」。30分が3分に。
ここでAPIもコードも一切書いていません。 アプリにコピペしているだけ。でもこの体験が「もっと自動化できないかな」という次の欲求を生みます。
Stage 1 で使うもの
| ツール | 月額（参考） | 特徴 |
|---|---|---|
| ChatGPT Plus | 約¥3,000 | ユーザー数最大、情報が多い |
| Claude Pro | 約¥3,000 | 長文処理に強い、コンテキスト理解が深い |
| Gemini Advanced | ¥2,900 | Google Workspace連携、マルチモーダル |
選び方の原則: 「どれが一番優れているか」ではなく「自分の業務で試して一番結果が良かったもの」を選ぶ。ベンチマークの順位と実務での使い勝手は別物です。複数試して、手に馴染むものを使えばいい。
Stage 2: 仕組み化する——コピペでは回らなくなったら
Stage 1 で業務にAIを使い続けると、処理できる仕事量が増えます。すると今度は 「毎回コピペするの面倒だな」「これ自動で回せないかな」 と感じるようになる。
この欲求が出てきたら Stage 2 です。ここで初めて「技術的な仕組み」の話になります。
仕組み化の選択肢——エンジニアがいるかで変わる
| チームの状況 | 推奨アプローチ | 具体例 |
|---|---|---|
| エンジニアなし | ノーコードツール | Dify、Flowise、GPTs、Zapier + AI |
| エンジニア1人以上 | AIエージェント or API連携 | Claude Code、Codex、LLM API + スクリプト |
エンジニアがいない場合: ノーコードツール
Dify や GPTs を使えば、コードを書かずに「社内データを参照するAIチャットボット」を構築できます。データのアップロードと設定だけで動く。
エンジニアがいる場合: 2つの道
道A: AIエージェントに任せる
2026年現在、Claude Code に自然言語で指示を出すだけでファイル検索、データ整理、コード生成、API呼び出しまで自律実行してくれます。
「salesフォルダのリード情報を読み込んで、
各企業への営業メール下書きをdraftsフォルダに生成して」
これだけで動きます。2024年頃は「エージェント = 難易度高」でしたが、2026年はコードを書くより自然言語で頼むほうが早いケースが増えています。
道B: LLM APIで自動化スクリプトを書く
定型的なバッチ処理（毎朝レポートを生成、フォーム送信を分類、等）はAPI + スクリプトが安定します。
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-4-6",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "弊社の営業メールを添削してください: ..."}
]
}'
モデル名やAPIバージョンは更新されることがあります。最新の情報はAnthropic公式ドキュメントで確認してください。
道Aと道Bの使い分け: 「毎回やることが微妙に違う」タスクはエージェント向き。「毎回同じ処理を繰り返す」タスクはAPIスクリプト向き。
社内データをAIに渡す——ベクトルDBは要らない
Stage 2に進むと「社内データをAIに参照させたい」という需要が出てきます。
2024年頃は「社内データ × AI = RAG（ベクトルDB + 検索パイプライン）」が定番でした。ですが2026年現在、小規模チームがRAGを組む必要はほぼありません。
理由は3つ:
1. コンテキストウィンドウが巨大化した
Claude の長コンテキスト対応モデル（例: Sonnet）は最大100万トークン（日本語で約75万字）のコンテキストウィンドウを持っています（モデルにより異なります）。社内の業務マニュアル、FAQ、議事録の大半はこの容量に収まります。
2. 構造化されたMarkdownのほうが精度が高い
Andrej Karpathy（元Tesla AI責任者）が提唱した「LLM Wiki」パターンは、Markdownファイルをフォルダで構造化してコンテキストに直接読み込む方式。ベクトル検索ベースのRAGと比較してより効率的と報告されています。
ベクトル検索は「意味が近い文」を引っ張ってくるだけなので、文脈や前後関係が欠落する。Markdownを丸ごと渡せば、LLMは文書全体の構造を理解して回答できます。
3. AIエージェントが検索を代行する
Claude Code などのAIエージェントは、ファイルシステムを直接走査して必要な情報を見つけます。「このフォルダの中から○○に関する情報を探して」と自然言語で指示するだけ。
実践: 社内ナレッジをAIに渡す方法
やることは3つだけです。
Step 1: 社内ナレッジをMarkdownで整理する
knowledge/
├── products/ ← 製品情報
│ ├── product-a.md
│ └── product-b.md
├── processes/ ← 業務プロセス
│ ├── onboarding.md
│ └── sales-flow.md
└── faq/ ← よくある質問
└── customer-faq.md
既存のドキュメントがWordやNotionにあるなら、Markdownにエクスポートしてフォルダに並べるだけ。
Step 2: インデックスファイルで構造を示す
# 社内ナレッジベース
## 製品情報
- [プロダクトA](products/product-a.md) — 主力サービスの仕様と料金
- [プロダクトB](products/product-b.md) — 2026年新規リリース
## 業務プロセス
- [オンボーディング](processes/onboarding.md) — 新入社員の初日〜1ヶ月
- [営業フロー](processes/sales-flow.md) — リード獲得から成約まで
Step 3: LLMに渡す
APIを使う場合はシステムプロンプトにMarkdownを含めるだけ。Claude Codeのようなエージェント環境なら、CLAUDE.mdにパスを書けばファイルを自動参照します。
RAGが有効な場面は残っています。数万件の文書を横断検索する必要がある大規模ナレッジベースや、リアルタイムに更新されるデータソース（チケットシステム、CRM等）を扱う場合です。ただし、それも2026年では「エージェントが検索ツールを呼ぶ」Agentic RAGパターンが主流で、従来のベクトル検索パイプラインを自前で組むケースは減っています。
スタック選定チェックリスト
Stage 2 に進む際のスタック選定です。
チェック1: チームの技術力
| 質問 | Yes → | No → |
|---|---|---|
| TypeScript / Python を書ける人がいるか | API連携 or エージェント活用 | ノーコードツール（Dify、GPTs等） |
| インフラ（サーバー、DB）の運用経験があるか | セルフホスト型も選択肢に | マネージドサービス一択 |
| 機械学習の経験があるか | ファインチューニングも視野に | プロンプトエンジニアリングに集中 |
小規模チームの現実: エンジニアがいなくても Stage 0 → Stage 1 は誰でもできます。Stage 2 のノーコードツールもハードルは低い。「エンジニアがいないからAI活用できない」は2026年では当てはまりません。
チェック2: 解きたい課題の種類
| 課題の性質 | 推奨アプローチ | 理由 |
|---|---|---|
| テキスト生成・変換が中心 | アプリで手動 or API | 追加インフラ不要 |
| 社内データを参照して回答したい | Markdown整理 + 大コンテキスト | ベクトルDB不要、即日構築可能 |
| 複数ステップの業務を自動化したい | エージェント（Claude Code等） | 自然言語で指示するだけ |
| 画像・音声を扱いたい | マルチモーダルAPI | 対応モデルが限られる点に注意 |
チェック3: 予算とスピード
| 条件 | 推奨 |
|---|---|
| 無料で始めたい | ChatGPT / Claude / Gemini の無料プラン（Stage 0） |
| 月額2,000〜3,000円 | 有料プラン（Stage 0-1を快適に） |
| より高い予算 | Claude Max プラン / ChatGPT Pro でエージェント活用（価格は各公式ページ参照）（Stage 2） |
| 月額10万円以上 | 専用インフラ + 複数エージェント並列稼働も視野 |
判断フロー——最初の一歩を決める
避けたほうがいい初手
AI開発を始めるとき、以下のパターンはコストに見合わないことが多いです。
いきなりAPIから入る
「AI開発 = APIを叩くこと」ではありません。まずアプリで体験を積む。APIが必要になるのは、自動化したい具体的な業務が見えてから。
ベクトルDBの構築から入る
2024年のベストプラクティスが「まずベクトルDBを立てる」だったので、古い記事を参考にするとここに行きがちです。2026年現在、100万トークンのコンテキストに直接Markdownを渡すほうが、構築コストゼロで精度も高い。ベクトルDBが必要になるのは、数万件規模の文書を扱うエンタープライズのケースです。
ファインチューニングから入る
汎用LLMのプロンプトエンジニアリングで解ける課題が大半です。ファインチューニングが必要になるのは、特殊なドメイン知識（医療、法律等）や、レスポンスのフォーマットを厳密に固定したい場合。最初から検討する必要はありません。
自社LLMのホスティング
オープンソースモデル（Llama 3等）をセルフホストするのは、GPU調達・運用コストが重い。データのプライバシー要件が極めて厳しい場合を除き、API利用で十分。
「AI戦略」の策定に時間をかける
戦略を立てる前に、まず触る。1週間AIで遊んでから得られる学びのほうが、1ヶ月の机上検討より価値があります。
実践ステップ——今日から始める
今日: AIアプリをインストールする
- ChatGPT、Claude、Gemini のどれか（または全部）をスマホとPCに入れる
- 何でもいいから話しかける。業務じゃなくていい
- 毎日何かしら使う習慣をつける
1週間後: 業務で1つ使ってみる
- 「手作業で15分以上かかっている」タスクを1つ選ぶ
- AIアプリにコピペしてやらせてみる
- Before/Afterの時間を測る
1ヶ月後: 仕組み化を検討する
- 「毎回コピペが面倒」なタスクをリストアップ
- エンジニアがいるなら、Claude Code やAPIスクリプトで自動化
- いなければ、Dify / GPTs でノーコード自動化
チェックリスト（印刷用）
最後に、AI活用の意思決定に使えるチェックリストをまとめます。
- AIアプリ（ChatGPT / Claude / Gemini）をインストールした
- 業務と関係なく1週間以上使い続けた
- 「これAIでいけるな」と感じる業務を1つ特定した
- その業務でAIを使い、Before/Afterの時間を計測した
- 仕組み化が必要か判断した（手動コピペで十分なら不要）
- 仕組み化する場合、チームの技術力に合った手段を選んだ
- ベクトルDBやRAGパイプラインを安易に選んでいないか確認した
まとめ
AI開発の始め方は、2026年になってもシンプルです。まずアプリで遊ぶ。業務で使ってみる。面倒になったら仕組み化する。
社内データを使いたくなったら、Markdownを整理してコンテキストに載せる。ベクトルDBやRAGパイプラインは、データが数万件を超えてから考えればいい。自動化したくなったら、Claude Code に自然言語で指示を出すところから。
小規模チームの強みは意思決定の速さなので、「まず触る → 足りないところを補強する」のサイクルを回すのが最も効率的です。
→ 気軽に相談する
