質問から公開まで:普通の人が AI Agent で実行力を広げる方法
普通の読者向けに、大規模モデルの仕組み、スレッド分割、Agent、Skill、MCP、Git、モデル選び、実践経験を整理した AI Agent 活用記事です。
# 質問から公開まで:普通の人が AI Agent で実行力を広げる方法
> 核心:AI は人を置き換えるものではなく、人の実行力を広げるものです。大事なのはコードを書けることではなく、仕事を分解し、正しく伝え、結果を確認できることです。
多くの人はまだ、AI を「一問一答」の道具として使っています。それも役に立ちますが、本当に効率を変えるのは、AI を作業を前に進める Agent として使うことです。背景、目標、制約、受け入れ基準を渡すと、AI はタスクを分解し、実行し、確認し、記録する手助けをしてくれます。
私が個人サイトを作る流れも同じです。まず GPT で曖昧なアイデアをサイトの位置づけ、ページ構成、ビジュアル方向、機能範囲に整理します。次に Codex を実際のプロジェクトに入れ、ファイルを読み、ルールに沿って修正、確認、記録更新を行います。最後の方向判断、範囲の取捨選択、受け入れ判断は人間が行います。
これは「一文で AI がサイトを作る」という話ではありません。実用的な流れは、人が判断し、AI が実行を増幅する、ということです。

## 1. AI の基本原理:次の Token を予測している
大規模モデルの回答は、ざっくり言えば「文脈から次の文字を予測する」ことです。より正確には、次の Token を予測しています。Token は文字、単語、数字、記号、コード片などです。
この理解は重要です。AI の特徴が見えてくるからです。
1. AI は全知ではなく、現在の文脈に合いそうな内容を生成します。
2. 入力が明確なほど、正しい方向に続けやすくなります。
3. 入力が乱れているほど、重要点を取り違えやすくなります。
4. 与えられていない事実は、推測してしまうことがあります。
5. 会話が長くなりすぎると、重要な情報が薄まり、文脈の外に出ることがあります。
つまり、AI 活用の第一原則は魔法のプロンプトではなく、文脈管理です。
## 2. 長いプロジェクトをスレッド分割する理由
多くの人は、一つのプロジェクトを最初から最後まで同じチャットで進めます。すると後半で AI が不安定になります。理由は単純で、古い履歴が多すぎるからです。AI は毎回、何が重要で、何が古く、何が途中案だったのかを判断しなければなりません。
私の経験では、長いプロジェクトは段階ごとに分けるべきです。
たとえばこう分けます。
```text
要件整理スレッド:目標、ユーザー、範囲、優先度
設計スレッド:構成、ページ、流れ、リスク
実行スレッド:明確なタスクを Agent に実行させる
バグ修正スレッド:現象、再現手順、期待結果
まとめスレッド:変更、経験、文書、次の一手
```
新しいスレッドを開くたびに、引き継ぎパックを渡します。
```text
プロジェクト背景:何のプロジェクトか
現在の状態:完了済みと未完了
今回の目標:今回だけで何をするか
制約条件:変えてはいけないこと、守るルール
関連ファイル:読むべき資料
受け入れ基準:何ができれば完了か
出力形式:一覧、案、コード、記事、PPT など
```
スレッドを替えるのは、最初からやり直すためではありません。AI の文脈をきれいに保つためです。

## 3. Agent の動き方
モデルは脳のようなものです。Agent は道具を持った作業担当者のようなものです。
普通のチャットは主に回答します。Agent は許可された範囲で、ファイルを読み、ツールを呼び、コマンドを実行し、ブラウザを開き、文書を編集し、画像を作り、PPT を出力し、チェックを走らせることができます。基本的な流れはこうです。
```text
タスク理解 -> 文脈読み込み -> 手順作成 -> ツール使用 -> 結果確認 -> 報告または修正継続
```
ここに Codex の価値があります。Codex は「こう直せます」と言うだけではありません。プロジェクトフォルダに入り、README、PROJECT_CONTEXT、CHANGELOG、プロジェクト Skill を読み、既存ルールに沿って作業できます。
ただし、Agent は自動的に信頼できるわけではありません。権限、ツール、文脈、受け入れ基準が必要です。境界のない Agent は単純な問題を複雑にしがちです。受け入れ基準のない Agent は、完了したかどうかを判断できません。
## 4. 知っておきたい基本概念
大規模モデル:理解、推論、生成を担う中心能力です。モデルごとに得意分野は違います。パラメータ規模、学習品質、データ、ツール、推論設計が性能に影響します。大きければ必ず良いわけではありません。
Token:AI が処理する基本単位です。入力や出力が長いほど、時間と費用は増えやすくなります。
コンテキストウィンドウ:AI が今見られる情報範囲です。範囲外の情報は、見えていないのと同じです。
Prompt:AI に渡す作業説明です。良い Prompt とは、良い引き継ぎです。
RAG:検索拡張生成です。AI が指定資料を先に検索し、その資料に基づいて答えます。社内知識庫や文書 Q&A に向いています。
微調整:専用データでモデルを追加学習し、特定タスクに合わせる方法です。多くの小さなチームでは、まず Prompt、知識庫、作業フローを整えるほうが効果的です。
Tool Calling:モデルに外部ツールを呼ばせる仕組みです。検索、表、ファイル、HTTP リクエスト、ブラウザ、データベースなどを使えます。
Skill:Agent 向けの専門作業手順です。ある種類のタスクについて、流れ、ルール、参考資料、スクリプトをまとめ、Codex が繰り返し安定して実行しやすくします。実務では、Skill は文書化されたプロンプトエンジニアリングです。
MCP:Model Context Protocol です。AI が外部ツールや文脈につながるための標準インターフェースと考えられます。MCP により、Codex は文書、ブラウザ、Figma、GitHub などに接続できます。
Git:バージョン管理ツールです。何を変更したかを記録し、戻す、比べる、共同作業することを楽にします。
GitHub:コードを置き、共同作業するためのプラットフォームです。repository はプロジェクトフォルダ、commit は保存記録、branch は作業分岐、PR は main に戻す前のレビュー依頼です。

## 5. 一番よく使う Prompt 公式
私がよく使う形はこれです。
```text
背景 + 目標 + 現在の状態 + 制約条件 + 受け入れ基準 + 出力形式 + やらないこと
```
弱い依頼はこうです。
```text
匿名チャットを作って。
```
より良い依頼はこうです。
```text
個人サイトに軽量な匿名チャットを追加したいです。目的は訪問者が公開メッセージを残せることです。
現在のサイトは Cloudflare Pages にデプロイされており、D1 データベースがあります。
第一版では、公開ルーム、テキストのみ、ランダムニックネーム、ローカルでのニックネーム記憶、文字数制限、送信クールダウン、ポーリング更新だけを作ります。
個別チャット、画像アップロード、複数ルーム、複雑な管理画面は作りません。
受け入れ基準は、スマホと PC で送信できること、更新後もメッセージが残ること、入力がスクリプトとして実行されないこと、既存の XP ピクセル風に合うことです。
まず案を出し、その後で最小利用可能版を実装し、プロジェクト文書も更新してください。
```
AI は難しいタスクが苦手なのではありません。推測させられるのが苦手です。

## 6. AI 活用の実践テクニック
第一に、先に AI に質問させます。要件が曖昧なときは、「不足情報とリスクを先に指摘し、まだ実行しないでください」と伝えます。
第二に、大きな仕事を小さく分けます。「サイトを作る」は、構成、ビジュアル、ホーム、ログイン、データベース、スマホ表示、デプロイ、文書化に分けられます。一度に一つだけ任せます。
第三に、やらないことを明確にします。多くのズレは、AI ができないからではなく、境界が書かれていないから起きます。
第四に、受け入れチェックリストを出してもらいます。「完了後、私が確認すべき点を列挙してください」と頼むと、結果を確認しやすくなります。
第五に、重要作業は先に案を出してもらいます。アカウント、データ、安全、費用、公開に関わる場合は、すぐ実行せず、案とリスクを先に出してもらいます。
第六に、長期ルールを文書に残します。README、PROJECT_CONTEXT、CHANGELOG、Skill に入れておくと、毎回口頭で説明し直す必要がありません。
第七に、こまめに引き継ぎパックを作らせます。スレッド終了前に、完了、未完了、重要決定、次の手順、注意点をまとめてもらうと、次のスレッドが安定します。
## 7. 現在の AI 市場
2026 年 6 月 14 日時点で、AI モデル市場は非常に混み合っており、一社独占ではありません。競争は大きく分けると次のようになります。
1. 汎用クローズド旗艦モデル:OpenAI GPT、Anthropic Claude、Google Gemini、xAI Grok。
2. 中国の大規模モデルと平台:Qwen / Alibaba Cloud Model Studio、DeepSeek、智譜 GLM、豆包 / 火山方舟、Kimi、MiniMax、Tencent Hunyuan など。
3. オープンウェイトの生態系:Meta Llama、Mistral など。ローカル実行、私有化、二次開発に向いています。
4. マルチモーダルとメディアモデル:画像、動画、音声、音声会話、文書理解が速く競争しています。
5. Agent 平台:モデルの強さだけでなく、ツール呼び出し、文脈管理、権限、安全、観測性、ワークフローが重要です。
ざっくり見るとこうです。
OpenAI:総合力、複雑な推論、コード、Agent、ツール利用に強い。
Claude:長文書、文章作成、コード、慎重な分析に強い。
Gemini:マルチモーダル範囲と Google エコシステムが広い。
DeepSeek:中国語とコード場面でよく注目され、コストや長文脈の選択肢として語られます。
Qwen / Alibaba Cloud Model Studio:中国での平台能力が強く、テキスト、画像、音声、動画、ベクトル、モデルサービスの範囲が広い。
Llama:研究、ローカル化、私有環境、制御性で重要なオープン生態系。
Mistral:オープンモデルと企業向けモデルを併せ持ち、コード、Agent、文書、マルチモーダル領域に展開しています。
Grok:xAI の汎用モデル群で、同社のエコシステムやツール利用と結びついています。
GLM、豆包、Kimi、MiniMax、Hunyuan:中国でよく使われる選択肢です。中国語能力、文脈長、価格、API、コンプライアンス、平台生態系で比較します。
モデル名はすぐ変わります。名前だけを覚えるより、選び方を覚えるほうが大切です。
## 8. 良いモデルとは何か
良いモデルとは、ランキング一位のモデルではありません。自分のタスクに合うモデルです。
見るべき項目は次の通りです。
1. 正確性:実際の質問で間違いが少ないか。
2. 指示追従:形式、境界、役割を守れるか。
3. 長文脈:長い文書、プロジェクト、会話を読んでも乱れないか。
4. 推論能力:複雑な問題を分解し、矛盾を見つけ、取捨選択を説明できるか。
5. ツール利用:検索、ファイル、コード、ブラウザ、データベースなどを安定して使えるか。
6. コード能力:プロジェクトを読み、慎重に編集し、テストし、リスクを説明できるか。
7. 中国語能力:中国語表現や業務文脈を理解できるか。
8. 費用と速度:高頻度タスクでは能力だけでなく価格と応答速度も重要です。
9. 安定性:同じタスクを複数回試して、結果が安定するか。
10. 安全とコンプライアンス:そのデータを外部モデルに渡してよいか。企業版、私有化、ローカルが必要か。
一番実用的なのは、自分の実タスクで小さな盲検比較をすることです。3 から 5 個の実問題を選び、複数モデルに答えさせ、正確性、使いやすさ、形式、速度、費用で採点します。公開ランキングだけに頼らないことです。
## 9. AI と Agent の選び方
文章作成、要約、ブレスト:自分にとって使いやすく、表現が安定した汎用モデルを選びます。
長文書分析:文脈長、引用の扱い、長文での安定性を優先します。
コードプロジェクト:プロジェクトを読み、ファイルを編集し、チェックを走らせられる Agent を選びます。Codex のようなワークフローが向いています。
PPT、画像、動画:対応するプラグインやマルチモーダル能力を持つツールを使います。純粋なチャットモデルだけで視覚作業の細部まで任せるべきではありません。画像、動画、ファイルに対応しているかも確認します。
社内知識庫:微調整より先に、RAG、権限、監査、データ安全を考えます。
高頻度で低リスクの作業:速くて安い小さめのモデルで十分なことがあります。
重要な意思決定資料:強いモデルを使ってよいですが、必ず人間が確認します。
プライバシー、契約、顧客、社内システム:まず会社のルールを確認し、必要なら企業版、私有化、ローカルモデルを使います。
## 10. 私の経験まとめ
第一に、AI が一番広げるのは怠けではなく明確さです。目標、境界、受け入れ基準が明確なほど、AI は使いやすくなります。曖昧な要件はまず対話型 AI に渡し、整理してもらうとよいです。知らないキーワードが出たらすぐ聞きます。複数の実行案を出してもらい、自分で選びます。
第二に、Agent は明確なタスクの実行に向いています。方向を決める役割ではありません。方向、取捨選択、責任は人間に残ります。
第三に、長いプロジェクトは必ず文書化します。背景、ルール、変更記録、次の一手は、一回のきれいな回答より重要です。プロジェクト文書、注意点、Skill、更新記録を用意し、新しいスレッドでは AI にそれらを読ませます。
第四に、一つのプラグインや Skill を過信しません。文章、コード、画像、PPT、知識庫、デプロイは、違う道具の組み合わせが必要なことがあります。ただし Skill が多すぎると文脈が重くなるので、絞って使います。
第五に、足りない情報は明示します。信頼できる AI 協作とは、空白を作り話で埋めることではなく、不確実性を見えるようにすることです。