# 補助的なコーディングから Agentic Coding へ：チームが AI プログラミングを本当に活用するには

1. AI プログラミング / Agentic Coding とは

AI プログラミングは、もはや「コードを数行すうぎょう補完する」だけのものではありません。

以前 AI coding と言うと、主に IDE の中で補完したり、コードを説明したり、関数を生成したりすることを指していました。いま言う Agentic Coding とは、AI が単にコードを生成するだけでなく、ひとつの目標を中心に継続して作業できることを指します。コードベースを読み、規約を理解し、タスクを分解し、ファイルを変更し、コマンドを実行し、テストを走らせ、結果を報告し、そのうえで人間のレビューを待つ、という流れです。

これは従来の「問答式 AI」とは次の点で異なります。

• 操作対象はテキストだけではなく、コードベース、ターミナル、テスト、ドキュメント、タスクフローです。
• 受け取る入力はひとつの prompt だけではなく、リポジトリのコンテキスト、チーム規約、ツール権限、実行境界です。
• 出力するものはコード片だけではなく、レビュー可能なプロセスと結果です。

OpenAI は『Introducing Codex』の中で、Codex を独立したクラウドサンドボックス内でタスクを並列処理できるソフトウェアエンジニアリング agent と定義し、リポジトリ内の AGENTS.md が agent にコードベースの辿たどり方、テストの実行方法、プロジェクト規約の守り方を伝えられることを明確に強調しています。Anthropic は『Claude Code overview』で、この種のツールをさらに直接的に定義しています。つまり、コードを読み、ファイルを変更し、コマンドを実行し、MCP に接続し、プロジェクト情報を記憶し、カスタムコマンドや hooks を使ってチームのワークフローを実行できるものです。

一言で言えば、AI プログラミングの重点は「コードを書けるかどうか」から、「実際のエンジニアリング環境で安定してタスクを完了できるか」へ移っています。

2. 現在の主流ツールはどのような姿か

今日の AI プログラミングツールは、大きく 4 種類に分けられます。

2.1 IDE インライン補完型

典型的な代表例は、Cursor、GitHub Copilot、Windsurf のような IDE 内ツールです。

これらの強みは次のとおりです。

• 速く、日常的なコーディング、補完、局所的な修正に向いている
• ほとんどフローを妨げない
• 「強化版エディタ」に近い

一方で、弱点も明らかです。

• 局所的なタスクに向いており、長い流れを持つタスクは得意ではない
• コンテキストは通常、現在のファイルや現在のセッションを中心にしている
• 「複数ステップの実行」への対応は限定的

2.2 ターミナル Agent 型

典型的な代表例は Codex CLI / App、Claude Code です。

この種のツールの特徴は次のとおりです。

• ターミナルやサンドボックス内で直接作業する
• 複数のファイルやディレクトリをまたいでタスクを完了できる
• コマンドを実行し、コードをテストし、ログを調べ、変更を生成できる
• 「補完プラグイン」ではなく、「共同開発者」により近い

これこそが、現在 Agentic Coding において最も注目すべき方向性です。

2.3 マルチ Agent / 非同期協作型

OpenAI は『Introducing the Codex app』の中で、Codex app を「agent command center」と定義しています。

この種のツールの核心は、単発の生成ではありません。むしろ次のような点にあります。

• 複数 agent の並列実行
• worktree / 隔離されたコピー
• 長時間タスクの非同期実行
• review queue
• automations による定期実行

これは、チームが「私と 1 つの AI が対話する」段階から、「私が一群の agent を調度して働かせる」段階へ入り始めていることを意味します。

2.4 企業プロセス接続型

本当に成熟した導入は、IDE やターミナルそのものにとどまらず、さらに下流へ接続されていきます。

• issue / ticket
• design
• docs
• CI
• release
• review

OpenAI の『How OpenAI uses Codex』と Anthropic の Claude Code ドキュメントはいずれも、同じことを強調しています。AI プログラミングは孤立したツールではなく、研究開発プロセスに接続された実行ノードなのです。

3. なぜ「コンテキストエンジニアリング」はモデルパラメータより重要なのか

モデルが上限を決めるものだとすれば、コンテキストエンジニアリングは下限を決めるものです。

同じ agent でも、規範も境界もツール制約もないリポジトリでは、しばしば「正しそうに見える」結果しか出せません。一方で、チームのルール、よく使うコマンド、外部依存、反復的なプロセスをきちんと固定化すると、その安定性は明らかに向上します。

だからこそ私は、チームには次の順番で優先的に整備することを勧めています。

1. AGENTS.md
2. Skill
3. MCP

逆ではありません。

3.1 AGENTS.md は最も基礎的な永続コンテキスト

AGENTS.md の価値は、「毎回あらためて説明しなければならないこと」をリポジトリ内に固定化できる点にあります。

入れるのに最も適している内容は、たとえば次のようなものです。

• リポジトリ構造をどう理解すべきか
• どのディレクトリは変更してよく、どこは触るべきではないか
• テストとビルドを実行する標準コマンド
• コードスタイル、コミット規約、レビュー要件
• コードを読むだけでは推測できない過去の落とし穴や業務上の制約

OpenAI は『Introducing Codex』と『How OpenAI uses Codex』のどちらでも、AGENTS.md の役割を明確に強調しています。これは agent に、継続的で安定した、タスク横断的なリポジトリコンテキストを与えるものです。

チームにとって、AGENTS.md が解決するのは 認識合わせ の問題です。

3.2 なぜ私はチームに Skill を優先的に使うことを勧めるのか

OpenAI は『Introducing the Codex app』の中で、skill を非常に明確に定義しています。skills bundle instructions, resources, and scripts。つまり skill は単なる一文の prompt ではなく、再利用可能で、実行可能で、共有可能な作業単位です。

私が MCP をデフォルトの答えにするより Skill を勧める主な理由は、5 つあります。

1. Skill はチームの方法論を蓄積するのに向いている

チームが本当に再利用したいものは、多くの場合「あるシステムに接続すること」ではありません。たとえば次のようなものです。

• code review をどう行うか
• changelog をどう書くか
• インターフェースドキュメントをどう同期するか
• 本番障害をどう調査するか
• リリース前チェックをどう行うか

これらの本質は 方法、手順、制約、スクリプト であり、「外部システム接続プロトコル」ではありません。

Skill はまさに、こうした内容を担うのに向いています。

2. Skill はバージョン管理とレビューがしやすい

Skill はリポジトリに直接置き、コードと一緒にレビュー、反復、ロールバックできます。

これはチームにとって非常に重要です。なぜなら、次のことを意味するからです。

• 変更を追跡できる
• ルールをレビューできる
• 経験を引き継げる
• 新メンバーが再利用できる

OpenAI も、skills は app、CLI、IDE extension の間で再利用でき、チーム共有のためにリポジトリへ check in することもできると明確に書いています。

3. Skill は通常、権限面が小さい

多くの Skill の中心は次のものです。

• 指示
• ローカルリソース
• 既知のスクリプト
• 固定されたワークフロー

それに対して MCP は、しばしば次のものを意味します。

• 追加の server
• リモート接続
• 外部認証
• リアルタイムデータアクセス
• 実行可能なツール呼び出し

チームガバナンスの観点では、Skill のほうが権限の収束とリスク管理を行いやすいのが普通です。

4. Skill は再現性が高い

Skill は「標準作業手順」に近いものです。

入力条件がだいたい同じであれば、出力経路も通常かなり安定します。たとえば次のようなものを作りやすくなります。

• プロジェクト onboarding skill
• リリースチェック skill
• API ドキュメント同期 skill
• 障害調査 skill

こうした資産の価値は、一回限りの prompt よりはるかに高いものです。

5. Skill は先に導入し、その後に拡張するのに向いている

多くのチームは最初から MCP の話を始めますが、結局次のところで止まりがちです。

• server をどうデプロイするか
• 認証をどう管理するか
• データをどう認可するか
• どの tool を実行可能にするか
• 監査をどう行うか
• 問題発生時にどう調査するか

一方で Skill は、導入のハードルがずっと低い。まず高頻度のプロセスを Skill 化するだけで、チームはすでに 70% の利益を得られます。

3.3 MCP とは何か。有用だが、デフォルトの答えではない

MCP の公式仕様は明確です。これは host / client / server アーキテクチャを持つ、JSON-RPC ベースのコンテキストとツールの交換プロトコルです。提供される中核的なプリミティブには次のものがあります。

• resources
• prompts
• tools
• sampling

つまり、MCP は「プロトコル層」や「接続層」に近いもの であり、チームの方法論そのものではありません。

もちろん有用です。特に次のような場面に向いています。

• Figma、Google Drive、Jira、Slack、Linear などの外部システムを読む
• AI をリアルタイムデータソースに接続する
• 明確なツール呼び出しインターフェースを公開する
• 複数の agent / host の間で統一的な接続を行う

しかし、MCP には構造的な欠点もあります。

3.4 MCP の現実的な問題

以下の判断は、MCP の公式仕様、OpenAI / Anthropic のドキュメント、そして実際のチーム導入経験に基づいて私が整理したものです。

1. MCP が解決するのは「接続」であり、「方法」ではない

MCP は agent に、リソースをどう取得するか、ツールをどう呼び出すかを教えることはできます。しかし、チームに次のことは教えてくれません。

• review をどう行うか
• コード規約をどう実行するか
• どのコマンドを走らせるべきか
• どの手順で人間の確認が必須か

これらはやはり AGENTS.md と Skill で補う必要があります。

2. MCP はガバナンスコストが高い

MCP を導入すると、取り込むのは単なる「能力」ではありません。追加の複雑性一式を導入することになります。

• host / client / server の関係
• capability negotiation
• 認証と権限
• サービス可用性
• 呼び出し失敗とリトライ
• 監査と責任追跡

多くのチームにとって、この複雑性は割に合いません。

3. MCP はセキュリティ面が大きい

MCP はしばしば、外部システムや実行可能なツールに接続します。

つまり、追加で次のことを考えなければなりません。

• どのデータを server に公開できるか
• どのツールを呼び出し可能にするか
• リモート server は信頼できるか
• ネットワークアクセスをどう制限するか
• prompt injection 後に影響範囲が拡大しないか

MCP の公式仕様自体も、user consent、data privacy、host 側のセキュリティ境界を強調しています。言い換えれば、仕様そのものが、これは高リスクな面であることを前提にしているのです。

4. MCP はプロジェクト内の暗黙的ルールを担うのに向いていない

プロジェクトで最も重要なものは、多くの場合 Jira ticket や Figma のデザインではなく、「チームだけが知っている」制約です。

• あるモジュールの歴史的な負債
• 触ってはいけないディレクトリ
• 変更してはいけないフィールド
• 必ず走らせるべきテストセット
• ある種の問題で最初に確認すべきログ

これらは MCP server に詰め込むより、AGENTS.md と Skill に書くほうが適しています。

3.5 より実用的な優先順位

チーム導入が目的なら、私が勧める優先順位は次の通りです。

1. まず AGENTS.md をきちんと書く
2. 高頻度のプロセスを Skill にする
3. 本当にリアルタイムの外部システムが必要なときだけ、MCP を接続する

つまり、こういうことです。

• AGENTS.md は「このプロジェクトをどう進めるべきか」を解決する
• Skill は「この作業をどう反復的かつ安定的に行うべきか」を解決する
• MCP は「この作業を外部システムに接続して行う必要がある」を解決する

この順番のほうが安定しており、チーム展開にも向いています。

3.6 原理：モデルはいつ MCP、Skill、CLAUDE.md、AGENTS.md を使うべきかをどう知るのか

ここは最も話が抽象的になりやすい部分です。

多くの共有では、これらをすべて一緒くたにして「モデルにコンテキストを食わせるもの」と説明します。しかし、それは十分に正確ではありません。それぞれの原理、トリガー方式、制御権は、実際にはまったく異なります。

まず、最も重要な判断を挙げます。

3.7 MCP の原理とは何か

MCP は「1 つのプラグイン」ではなく、プロトコルのセットです。

公式仕様では、MCP は host / client / server アーキテクチャとして定義されています。

• host は調整、認可、安全ポリシーの実行を担当する
• client は host を代表して特定の server に接続する
• server は prompts、resources、tools などの能力を公開する

MCP の基礎通信は JSON-RPC です。標準的な lifecycle は明確です。

1. まず initialize
2. capability negotiation を行う
3. その後、通常の operation に入る

つまり、モデルが最初から「すべてのツールを知っている」わけではありません。まずホストが利用可能な能力を交渉で明確にし、その後モデルとアプリケーションはその境界内で動きます。

3.8 MCP は結局どうトリガーされるのか

ここは 3 種類に分けて見る必要があります。公式仕様にも明確に書かれています。

• Prompts は user-controlled
• Resources は application-controlled
• Tools は model-controlled

この 3 種類はどれも「能力」のように見えますが、トリガーの仕組みはまったく異なります。

3.8.1 MCP Prompts：ユーザーがトリガーする

MCP prompt は、再利用可能なテンプレートコマンドに近いものです。

通常、次のようなタイミングでトリガーされます。

• ユーザーがメニューから選ぶ
• ユーザーが slash command を実行する
• ユーザーが特定の prompt テンプレートを明示的に呼び出す

したがって prompt は、モデルがこっそり自分で使うものではなく、ユーザーが選び、ホストがテンプレートを展開してモデルに渡すものです。

3.8.2 MCP Resources：アプリケーションまたはユーザーが参照したときにトリガーされる

Resource はコンテキストであり、アクションではありません。

典型的なトリガー方法は 2 種類あります。

• ホストが自動で添付する
• ユーザーが明示的に参照する

Anthropic の Claude Code ドキュメントには、かなり具体的な例があります。MCP resource はファイルのように @server:protocol://path で参照できます。一度参照されると、そのリソースは自動で取得され、attachment としてコンテキストに入ります。

つまり resource の本質は「モデルに実行させること」ではなく、外部コンテンツをモデルに見せることです。

3.8.3 MCP Tools：モデルが呼び出すかどうかを決める

Tool こそが、「agent が外部世界で手を動かす」ことに最も近い層です。

MCP の公式仕様によれば、tool は model-controlled です。つまり：

• ホストがまず呼び出し可能なツールを公開する
• モデルが推論中に、それを使う必要があるか判断する
• 実際の実行前後でも、権限、隔離、確認、ログはホストが担当する

したがって「モデルが MCP をどうトリガーするのか」という言い方が厳密に成り立つのは tools 部分だけです。prompts と resources については、同じ種類のトリガーロジックではありません。

3.9 Skill の原理とは何か

Skill は外部接続プロトコルではなく、読み込み可能なワークフローパッケージです。

OpenAI は「Introducing the Codex app」で、skills は instructions, resources, and scripts を bundle するものだと定義しています。Anthropic の Agent Skills ドキュメントは、さらに詳しく原理を説明しています。Skill は VM / ファイルシステム内のディレクトリであり、その中に SKILL.md、スクリプト、参考資料を置き、Claude は progressive disclosure によって段階的に読み込みます。

これは非常に重要です。なぜなら、Skill がチーム導入により向いている理由を説明しているからです。

Skill の本質は「外部システムを接続すること」ではありません。そうではなく：

• チームの方法論をパッケージ化する
• 説明、リソース、スクリプトを同じ単位にまとめる
• モデルが必要なときに読み込めるようにし、常にコンテキストを占有しないようにする

3.10 Skill はどうトリガーされるのか

3.10.1 OpenAI / Codex の公開説明

2026 年 2 月 2 日時点の OpenAI「Introducing the Codex app」では、公式の公開説明として次のように述べられています。

• Codex に特定の skill を使うよう明示的に要求できる
• 現在のタスクに基づいて自動的に使わせることもできる

OpenAI の公開資料では、Anthropic のように内部の読み込み階層メカニズムを細かく書いてはいません。公開情報に基づくなら、比較的堅い理解は次のとおりです。

• skill には少なくとも「発見可能な説明情報」がある
• agent はタスクの意味に基づいて skill ルーティングを行う
• ヒット後、その skill 内の instructions / resources / scripts を使う

最後の 2 点は公開されている挙動に基づく推論であり、OpenAI が現時点の公開ドキュメントで逐条的に固定している実装詳細ではありません。

3.10.2 Anthropic / Claude の公開説明

Anthropic はこの部分をより詳しく公開しています。

公式ドキュメントでは、Skill のトリガーは 3 層として説明されています。

1. Metadata は常駐読み込み
   name と description は起動時にシステムプロンプトに入り、発見とマッチングに使われます。
2. SKILL.md 本文 はトリガー時に読み込み
   ユーザーの依頼が skill の説明とマッチしたときにだけ、Claude は SKILL.md を読みます。
3. 追加リソースとスクリプト は必要に応じて読み込み
   本文内で追加ドキュメントやスクリプトが参照されたときにだけ、Claude はさらに読み取りまたは実行を続けます。

これが典型的な progressive disclosure です。

つまり、Skill のトリガーは「skill パッケージ全体が常にコンテキストに入る」というものではありません。

• まず「どんな skill があるか」を知る
• 次に「現在のタスクがこの skill に似ているか」を判断する
• ヒット後に初めて説明書を読む
• さらに材料が必要なときにだけ展開を続ける

これこそが、Skill が「長大なシステムプロンプト」より効率的である根本的な理由です。

3.11 CLAUDE.md は何のためのものか、いつ使われるのか

CLAUDE.md はコマンドでもプラグインでもありません。これは Claude Code の永続指示ファイルです。

Anthropic の公式ドキュメントは非常に直接的に書いています。

• CLAUDE.md は、プロジェクトのルール、ワークフロー、アーキテクチャ情報を Claude に継続的に伝えるためのもの
• Claude は各 session の開始時に読む
• 上位ディレクトリの CLAUDE.md は起動時に全文読み込まれる
• 子ディレクトリ内の CLAUDE.md は、Claude が対応するディレクトリのファイルを読んだときに必要に応じて読み込まれる

さらに重要なのは、Anthropic がこれを auto memory と区別していることです。

• CLAUDE.md は、あなたが書く instructions and rules
• auto memory は、Claude 自身が蓄積する learnings and patterns

つまり、CLAUDE.md の原理は「記憶庫」ではなく、あなたが手作業で保守し、レビュー可能で、session をまたいで有効になる体系的な説明書です。

「大規模言語モデルはいつ CLAUDE.md を使うのか」と聞くなら、最も正確な答えは次のとおりです。

• 会話開始時点ですでに使う
• 特定のディレクトリに入る / 特定のファイルを読むと、より細かい粒度のルールが追加で読み込まれる
• モデルがその場で思いついて探しに行くものではなく、Claude Code のコンテキスト装填メカニズム自体が処理する

Anthropic はさらに .claude/rules/ という層も追加しています。

• パス制限のないルールは、起動時に読み込まれる
• paths 付きのルールは、マッチするファイルが読まれたときだけトリガーされる
• 公式はさらに、「タスク型で、常駐型ではない」説明については、常駐 rules に全部詰め込むのではなく、Skill を優先すべきだと明記している

これはかなり参考にすべき点です。

3.12 AGENTS.md は何のためのものか、いつ使われるのか

まず名前を 1 つ訂正します。

2025年5月16日時点の OpenAI「Introducing Codex」と、2025年10月の「How OpenAI uses Codex」の公開資料によると、OpenAI 公式が使っている名前は AGENTS.md であり、agent.md ではありません。

Codex 体系における AGENTS.md の役割は、CLAUDE.md とかなり近いものですが、公開されている詳細は Anthropic ほど細かくありません。

OpenAI 公式がすでに明確に公開している点は 2 つあります。

• AGENTS.md は、Codex にコードベースのたどり方、実行すべきテスト、従うべきプロジェクト規約を伝えられる
• Codex に persistent context を提供できる

つまり、本質的にはこれもリポジトリ単位の持続的な説明ファイルだと言えます。

ただし注意すべきなのは、OpenAI の公開資料では現時点で Anthropic のように「読み込み順序、サブディレクトリごとのオンデマンド読み込み、パスルールによるトリガー」をそこまで明確には書いていないという点です。

そのため、より堅実な結論は次のとおりです。

• AGENTS.md は、Codex が repo タスクを処理するときに継続的なコンテキストとして参照される
• プロジェクト規約、コマンド、境界、アーキテクチャ上のヒントを置くのに適している
• 「外部ツールのトリガー」ではなく、「質問されたときだけ一時的に読み込まれる知識ブロック」でもない

さらに一歩踏み込んで「Codex は必ずいつ AGENTS.md を読み込むのか、必ずどの順序でマージするのか」と言い切ると、それは現時点の公開資料を超えています。この部分は実装レイヤーの推測にとどめるべきで、確定的な結論として書くのには向いていません。

3.13 この 4 種類の仕組みを一言で説明する

共有の場でこれらを一言で区別するなら、私は次のように説明するのがよいと思います。

• AGENTS.md / CLAUDE.md：リポジトリやプロジェクトの長期的な説明書
• Skill：タスクに応じてトリガーされるワークフローパッケージ
• MCP Resource：外部システムの参照可能なコンテキスト
• MCP Tool：モデルが境界内で呼び出せるアクションインターフェース

この 4 種類を切り分けて理解できれば、「AI コーディングがなぜあるときは非常に強く、あるときは妙に鈍いのか」という多くの現象も説明できるようになります。

4. 安全性、サンドボックス、権限管理をどう設計するか

AI プログラミングでは、効率だけでなく、必ず境界について語る必要があります。

なぜなら、agent がファイルを読み、コードを変更し、コマンドを実行し、ネットワークに接続できるようになった時点で、そのリスクモデルは普通のチャットボットとはまったく別物になるからです。

Anthropic は《Making Claude Code more secure and autonomous with sandboxing》の中で、この点を非常に明確に説明しています。真に重要なのは、次の 2 層の隔離です。

• ファイルシステムの隔離
• ネットワークの隔離

この 2 層が同時に備わっていて初めて、「agent により安全に自律実行させる」ことについて語れるようになります。

OpenAI も《Introducing the Codex app》で似た方向性を示しています。デフォルトでは agent が作業ディレクトリ内のファイルだけを編集できるようにし、ネットワークは制限し、境界を超えるコマンドについては改めて承認を求める、という考え方です。

チームで実運用する場合、少なくとも次の点は満たすべきだと思います。

4.1 デフォルトは最小権限にする

出発点としては、次の設定を推奨します。

• デフォルトは読み取り専用
• デフォルトでは現在の作業ディレクトリだけを許可する
• デフォルトではネットワーク禁止、またはキャッシュ検索のみ許可する
• デフォルトでは高リスクなコマンドを許可しない

最初から agent に全体の読み書き権限や自由なネットワークアクセスを与えるべきではありません。

4.2 ファイルシステムの境界を明確にする

最も基本的な制限には、次のようなものが含まれるべきです。

• 現在の repo または現在の worktree だけを変更可能にする
• 機密ディレクトリへのアクセスを禁止する
• SSH key、署名鍵、グローバル設定には触れさせない
• 成果物ディレクトリ、キャッシュディレクトリ、一時ディレクトリを個別に制約する

4.3 ネットワーク権限はホワイトリスト化する

agent にネットワークアクセスが必要な場合は、明確なドメインだけを開放することを推奨します。

• ドキュメントサイト
• パッケージリポジトリ
• 指定された API
• 指定された内部サービス

「任意の外部通信」は許可すべきではありません。

4.4 どんな越権も可視化されるべき

理想的な状態は「絶対に間違えない」ことではなく、次のような状態です。

• 境界を越えた瞬間に止められる
• すべてのステップにログが残る
• 実行したコマンドを追跡できる
• 見た出力を後から確認できる

これは、単に「モデルを信頼する」ことよりも重要です。

4.5 高リスクな操作は人間に残す

次のような操作は、デフォルトで人間の確認を残すことを推奨します。

• リモートブランチへの push
• 本番設定の変更
• 大量のファイル削除
• データベース変更の実行
• 実際のオンライン書き込み API の呼び出し
• 機密性の高い業務データへのアクセス

Agent は操作の準備まではできますが、最後の一歩は自動化しないほうがよいです。

5. 効果をどう測るか、デモだけを見ない

AI プログラミングでチームが最も誤解しやすいのは、demo がどれも強力に見えることです。

しかし本当に答えるべき問いは、「例を 1 つ作れるか」ではなく、次のようなものです。

• 実際のタスクを安定して処理できるか
• チーム環境で再現できるか
• どれだけの手戻りとレビューコストを持ち込むか
• 本当に効率化しているのか、それともコストを後ろにずらしているだけなのか

5.1 外部 benchmark で何を見られるか

SWE-bench は、現時点で最も引用する価値のある公開基準の 1 つです。

その価値は次の点にあります。

• 実際の GitHub issue を使っている
• 再現可能な Docker 評価環境がある
• 「本当に問題を解決し、テストを通せるか」を見ている
• 見栄えのするコード片を生成できるかだけを比べているわけではない

この種の benchmark は、なぜ AI プログラミングの評価をデモ動画や単発のサンプルだけで見てはいけないのかを説明するのに非常に適しています。

5.2 ただしチームは benchmark だけを見るべきではない

SWE-bench が解決しているのは、「公開タスクにおけるモデル / agent の能力比較」です。これは「あなたのチームがすでに効率化できている」こととは等しくありません。

チームが本当に見るべきなのは、自分たちの内部指標です。

5.3 より追跡すべき 8 つの指標

私は、チームには次のような指標を追うことをより勧めます。

これらの指標は、「生成速度が速い」「賢そうに見える」よりもはるかに有用です。

5.4 シンプルな評価の階層

AI プログラミングの評価は、三層に分けることを勧めます。

第一層：公開 benchmark

SWE-bench のような、モデルと agent の汎用的な上限を見るものです。

第二層：チーム標準タスク集

自分たちで固定タスクのセットを作ります。たとえば次のようなものです。

• 実際の bug を 1 つ修正する
• インターフェースのフィールドを 1 つ追加し、ドキュメントも同期する
• テストを一組追加する
• リファクタリングを 1 回行う
• 本番アラートを 1 回処理する

この層が最も重要です。

第三層：実際の開発指標

最終的には次を見ます。

• デリバリーサイクルが短縮されたか
• 手戻り率が下がったか
• 本番障害が増えていないか
• ドキュメントとプロセスがより完全になったか

第三層が改善して初めて、AI プログラミングは本当に定着したと言えます。

6. チーム導入の提案：まず Skill、その後 MCP

もし私がチームに非常に実務的な導入順序を提案するなら、次のように勧めます。

第一歩：まず AGENTS.md を正しく書く

少なくとも次を明確に書きます。

• プロジェクト構造
• 主要コマンド
• テストとビルドの方法
• 触れてはいけない境界
• コミットとレビューの要件

第二歩：高頻度タスクを Skill にする

優先的に Skill 化する価値が最も高いのは、通常次のようなものです。

• code review
• changelog 生成
• リリースチェック
• API ドキュメント同期
• 問題調査
• 新メンバー onboarding

第三歩：「外部システム接続が必須」の能力だけを MCP に接続する

たとえば次のようなものです。

• Figma
• Jira / Linear
• ドキュメントライブラリ
• 読み取り専用データシステム

すべてを MCP に詰め込まないことです。

第四歩：最後に自動化と multi-agent を検討する

AGENTS.md、Skill、安全境界、評価方法がある程度安定してから、次に進みます。

• automations
• multi-agent
• 長時間タスクの非同期実行
• 定期巡回チェック

この順序のほうが、「先に大量のツールを接続してから、あとでガバナンスを少しずつ補う」よりも、はるかに確実です。

7. 共有に向いた核心的な結論

今回の共有で 4 文だけ残すなら、次の 4 文を話すのがおすすめです。

1. AI プログラミングはすでに「コード補完」から「Agentic Coding」に入り、重点は実際のエンジニアリング環境でタスクを完了できるかどうかに移っています。
2. チーム導入の鍵はモデルパラメータではなく、コンテキストエンジニアリングです。特に AGENTS.md と Skill が重要です。
3. MCP は非常に有用ですが、外部システム接続により適しており、チームの方法論を置き換えるべきではありません。デフォルトの優先順位は AGENTS.md > Skill > MCP であるべきです。
4. AI プログラミングの評価は demo だけを見てはいけません。サンドボックス、安全境界、実タスク完了率、長期的な開発指標を見る必要があります。

付録：核心的な参考資料

最も読み込む価値がある 5 本

• OpenAI「Introducing Codex」
• OpenAI PDF「How OpenAI uses Codex」
• Anthropic「Claude Code overview」
• MCP 公式仕様
• SWE-bench 公式 Overview

補足に適した資料

• OpenAI「Introducing the Codex app」
• Anthropic「How Claude remembers your project」
• Anthropic「Agent Skills Overview」
• Anthropic「Making Claude Code more secure and autonomous with sandboxing」
• MCP Architecture
• MCP Server Features Overview
• OpenAI「Codex is now generally available」
• OpenAI「Introducing upgrades to Codex」

二次参考層：講演、共有、経験資料をどう取り込むか

この種の資料は非常に価値がありますが、使い方は分けて考える必要があります。

私のおすすめは、資料を 2 つの層に分けることです。

• 一次資料：公式ドキュメント、公式ブログ、公式仕様
  「事実層」と「仕組み層」を定義するために使う。
• 二次資料：個人講演、経験共有、第三者による解説
  「話し方の層」「ケース層」「視点層」「論点」を補うために使う。

つまり：

• 原理、定義、発火タイミングについては、OpenAI / Anthropic / MCP の公式資料を優先して引用する
• 事例、経験、テーマ設定の角度、共有の流れについては、以下の二次資料を引用してよい
• 二次資料の中に強い事実判断が出てきた場合は、本文に書き込む前に一次資料に戻って確認するのがよい

Geoffrey Challen「A Day With Claude: Using and Teaching Coding Agents」

• リンク：Geoffrey Challen「A Day With Claude: Using and Teaching Coding Agents」
• 置くのに適した場所： Agentic Coding とは何か、チームの働き方はどう変わるか、教育と組織はどう適応するか
• 引用に適したポイント： この資料は、完成度の高い keynote のような構成です。単にツールを紹介するのではなく、「Plan -> approve -> agent が実装 -> テストで検証」という新しい働き方を、一本のストーリーラインとして語っています。
• 参考にできる内容：
  • 定義を最初から積み上げるのではなく、「1 日のワークフロー」で agentic coding を語る
  • 「実装を反復する」から「計画を反復する」への変化を強調する
  • テストは付属品ではなく、agent loop の secret weapon であると強調する
  • 組織と教育システムは、この新しい働き方に適応する必要があると強調する
• ドキュメントに書き込む際の提案： これは「トレンドと働き方の変化」の章に、経験事例として置くのに向いています。彼個人の利用データを、そのまま業界全体の一般的結論として扱わない方がよいです。

Claude Code Anonymous「Agentic Coding: Real Talk from the Trenches」

• リンク：Claude Code Anonymous「Agentic Coding: Real Talk from the Trenches」
• 置くのに適した場所： テーマ設定の角度集、よくある誤解、経験型共有の素材
• 引用に適したポイント： これは 1 本の資料というより、presentation collection 全体です。その価値は主に「権威ある結論を 1 つ与えてくれる」ことではなく、「他の人がどんな角度から agentic coding を語っているか」を探す助けになる点にあります。
• 参考にできる内容：
  • タイトルの見せ方
  • 経験型 talk の切り口
  • どの話題が共感を呼びやすいか
  • どの概念を 1 ページに切り出すとよいか
• ドキュメントに書き込む際の提案： 本文で大量に引用する必要はありません。別途「共有テーマの参考プール」のような小節を作り、今後素材を整理する際のインスピレーション源として使うのがよいです。

Mitsuhiko「Agentic Coding: The Future of Software Development with Agents」

• リンク：Mitsuhiko「Agentic Coding: The Future of Software Development with Agents」
• 置くのに適した場所： 全体概観、なぜ agentic coding が急に立ち上がったのか、ツール全景
• 引用に適したポイント： これは全体像を示す視点として非常に使いやすい資料です。agentic coding の定義が比較的明確であり、ツール、workflow、observability、context conservation についても明示的に論じています。
• 参考にできる内容：
  • agentic coding を「AI が単にコードを提案するだけでなく、planning / implementing / refining に参加するソフトウェア開発プロセス」と定義する
  • ツールと workflow の設計原則を強調する
  • 「MCP が多すぎると context rot がより早く起きる」と明確に指摘し、coding agents に対して MCP を慎重に使うことを提案している
• ドキュメントに書き込む際の提案： これは、現在の「Skill 優先、MCP は補助」という論証を強化するのに非常に適しています。公式仕様ではありませんが、実践的な観点から強い裏付けを提供してくれます。

hiromitsusasaki「The World Has Changed」

• リンク：hiromitsusasaki「The World Has Changed」
• 置くのに適した場所： 業界概観、Plan モード / Spec-driven development、エコシステムの変化
• 引用に適したポイント： この資料は新しく、話したい方向性にもかなり近いです。spec-driven development、Plan モードの普及、Kiro / Claude Code / Copilot / Cursor といったエコシステムの変化を一つにつなげています。
• 参考にできる内容：
  • 「先に plan、後で coding」が主流のインタラクションモードになりつつある
  • spec-driven development は agentic coding の上位方法論として扱える
  • ツールエコシステムは、単一の補完から「複数ツールの併存 + ワークフローの階層化」の段階に入っている
• ドキュメントに書き込む際の提案： 「なぜ今急に盛り上がっているのか」と「働き方はどう変わりつつあるのか」の 2 節に置くのに非常に適しており、視点を一段引き上げる助けになります。

Gota「CodexでもAgent Skillsを使いたい」

• リンク：Gota「CodexでもAgent Skillsを使いたい」
• 置くのに適した場所： Skill vs MCP、Skill の考え方を Codex にどう移植するか、コンテキストエンジニアリング
• 引用に適したポイント： これは私たちのドキュメントの現在の主線とかなり一致しています。明確に次の点を扱っています。
  • MCP server の読み込みはかなりの token を消費する
  • MCP をつなぎすぎるとツール選択の精度が下がる
  • Skill は階層的にロードできる
  • AGENTS.md を使って Codex に Skill を認識させ、自律的に選ばせることができる
• 参考にできる内容：
  • L1 メタデータ / L2 SKILL.md / L3 スクリプトという構造で Skill を説明する
  • なぜ coding agent には、MCP を無限に積むより Bash / Shell + Skill の方が向いているのかを説明する
  • AGENTS.md が「Codex に選択可能な Skill を知らせる」役割を担えることを説明する
• ドキュメントに書き込む際の提案： この資料は重点的に取り込むべきです。特に、既存の「なぜ Skill は MCP よりチームに適しているのか」の節を補強するのに向いています。

Sunagaku『Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし術』

• リンク：Sunagaku『Codexを使い倒して気づいた、Claude Codeの本当の強みと使いこなし術』
• 置くのに適した場所： 実践テクニック、multi agent / review agent、ツール比較
• 引用に適したポイント： この種の資料の最大の価値は、定義を与えることではなく、「実際にどう使うのか」をより地に足のついた形で語る助けになる点です。
• 参考にできる内容：
  • Codex と Claude Code の違いをどう説明するか
  • subagent / review agent のような実践的な使い方をどう説明するか
  • 経験を「そのまま真似できる」workflow としてどう語るか
• ドキュメントに書き込む際の提案： 前半の原理の章ではなく、後半の「使用テクニック / 実践経験」部分に置く方が適しています。

PromptLayer『Watch my AI Engineering talk: How Claude Code Works』

• リンク：PromptLayer『Watch my AI Engineering talk: How Claude Code Works』
• 置くのに適した場所： agent loop の原理、なぜ Bash が重要なのか、なぜ subagent が有効なのか
• 引用に適したポイント： こちらはより「原理の分解」に寄った資料です。強調されている以下の点は、かなり取り込む価値があります。
  • CLAUDE.md は本質的には編集可能な markdown の説明ファイルである
  • Bash は coding agent にとって universal adapter である
  • subagent の価値は、子タスクを独立したコンテキストウィンドウに隔離し、メインコンテキストの汚染を避けられる点にある
• ドキュメントに書き込む際の提案： 「Skill / コンテキストエンジニアリング / agent loop」の近くに補足として入れるのに向いており、「なぜシンプルなツールの組み合わせがかえって有効なのか」を説明する材料になります。

これらの二次資料を現在のドキュメントにつなげる方法

次のように導入することを提案します。

1. 「Agentic Coding とは何か」に Geoffrey と Mitsuhiko を補う
   全体像と働き方の変化に関する語りを強化するためです。
2. 「Skill / MCP / AGENTS.md / CLAUDE.md の原理」に Gota と PromptLayer を補う
   Skill の階層的ロード、Bash、subagent、MCP の限界といった観点を強化するためです。
3. 「なぜ今盛り上がっているのか」と「業界の変化」に hiromitsusasaki を補う
   spec-driven development、Plan モード、エコシステムの変化をつなげるためです。
4. 「実践テクニック」または将来の「経験編」に Sunagaku と Claude Code Anonymous を補う
   事例、タイトルの切り口、実践経験を充実させるためです。

現段階での使用原則

現段階では、本文では次の原則を保つことをおすすめします。

• 仕組み、定義、トリガー方法：公式ソースを優先する
• 経験、語り方、実践的な見解：これらの共有資料で補足する
• 議論の余地がある判断：「プロトコル上の事実」ではなく「実践上の見解」と明示する