補助的ほじょてきコーディングから統合型とうごうがた開発かいはつへ

チームはどのようにAIプログラミングを本当ほんとうに使つかいこなすのか

Plan / Skill / AGENTS.md / 安全あんぜん境界きょうかい / 効果こうか評価ひょうか

1. まず概念がいねんをはっきりさせる

AIプログラミングとは何なにか

• ただコードを補完ほかんするだけではない
• ただ「このコードはどんな意味いみか」に答こたえるだけではない
• ただ1つの関数かんすうやコンポーネントを生成せいせいするだけではない

いま、より正確せいかくな言いい方かたは：

Agentic Coding

AIが1つの目標もくひょうを軸じくに継続的けいぞくてきに作業さぎょうする：

• コードベースを読よむ
• 規約きやくを理解りかいする
• 作業さぎょうを分解ぶんかいする
• ファイルを修正しゅうせいする
• コマンドを実行じっこうする
• テストを実行じっこうする
• 結果けっかを報告ほうこくする

Agentic Codingと従来じゅうらいのAIコーディングの違ちがい

layout: section

2. 主流しゅりゅうツールはどんな形かたちか

今日きょうの主流しゅりゅうツールの4つの形態けいたい

1. IDE内ないインライン補完ほかん型がた
   Cursor / Copilot / Windsurf

2. ターミナルAgent型がた
   Codex CLI / App / Claude Code

3. 複数ふくすうAgent / 非同期ひどうき協業きょうぎょう型がた
   worktree、review queue、automations

4. 企業きぎょうプロセス接続せつぞく型がた
   issue / docs / CI / design / review

IDE内ないインライン補完ほかん型がた

利点りてん：

• 速はやい
• 集中しゅうちゅうの流ながれを途切とぎらせない
• 日常的にちじょうてきなコーディングに向むいている
• 局所的きょくしょてきな修正しゅうせいに向むいている

限界げんかい：

• より短みじかい作業さぎょうに向むいている
• 複数ふくすう段階だんかいの作業さぎょうは能力のうりょくに限界げんかいがある
• コンテキストは通常つうじょう現在げんざいのファイルを中心ちゅうしんとする

結論けつろん：

より「強化版きょうかばんエディタ」に近ちかい

ターミナルAgent型がた

代表例だいひょうれい：

• Codex App / CLI
• Claude Code

特徴とくちょう：

• コードベースを直接ちょくせつ操作そうさする
• ディレクトリをまたいでファイルを修正しゅうせいできる
• コマンドやテストを実行じっこうできる
• より大おおきな作業さぎょう、長ながい作業さぎょうに向むいている
• より「共同きょうどう開発者かいはつしゃ」に近ちかい

結論けつろん：

これはAgentic Codingで最もっとも注目ちゅうもくに値あたいするルートである

複数ふくすうAgent / 非同期ひどうき協業きょうぎょう型がた

キーワード：

• 複数ふくすうagentの並列へいれつ実行じっこう
• worktreeによる分離ぶんり
• review queue
• automations
• 長時間ちょうじかん作業さぎょうの非同期ひどうき実行じっこう

何なにが変かわるのか：

「私わたしと1つのAIが対話たいわする」から

次つぎの状態じょうたいへ

「私わたしが1組くみのagentに仕事しごとを割わり振ふる」

layout: section

3. 本当ほんとうに効果こうかを決きめるのはモデル参数ぱらめーたではない

なぜコンテキストエンジニアリングのほうが重要じゅうようなのか

同おなじモデルでも：

• 規約きやくがないと、出力しゅつりょくはしばしば「正ただしそうに見みえる」
• 境界きょうかいがないと、権限けんげんを越こえやすい
• プロセスがないと、手戻てもどりと審査しんさコストが高たかい

いったんルール、コマンド、境界きょうかい、プロセスを固定化こていかすると：

• 安定性あんていせいが向上こうじょうする
• 再利用性さいりようせいが向上こうじょうする
• チーム協業きょうぎょうコストが下さがる

私わたしが勧すすめるチーム構築こうちく順序じゅんじょ

AGENTS.md > Skill > MCP

理由りゆう：

• AGENTS.mdはプロジェクトの統一とういつ方針ほうしんを解決かいけつする
• Skillは高頻度こうひんどプロセスの再利用さいりようを解決かいけつする
• MCPは外部がいぶシステム接続せつぞくを解決かいけつする

この順番じゅんばんを逆ぎゃくにしてはいけない。

AGENTS.mdは何なにのためのものか

それは：

リポジトリ単位たんいの永続的えいぞくてき説明書せつめいしょ

何なにを書かくのに向むいているか：

• リポジトリ構造こうぞう
• 変更へんこうしてよいもの、してはいけないもの
• テストとビルドのコマンド
• コードスタイルとレビュー要件ようけん
• 過去かこの落おとし穴あなと業務ぎょうむ制約せいやく

価値かち：

• 毎回まいかいの対話たいわでプロジェクトルールを自動的じどうてきに含ふくめられる
• 「プロジェクト背景はいけいの説明せつめいを繰くり返かえす」コストを下さげる

なぜSkillのほうがMCPよりチームでの初期しょき導入どうにゅうに向むいているのか

Skillがより適てきしているのは：

• code review
• changelog生成せいせい
• YApi docs-sync
• 問題もんだい調査ちょうさ
• 公開前こうかいまえ確認かくにん
• onboarding

本質的ほんしつてきには：

方法ほうほう、手順てじゅん、制約せいやく、スクリプト

であり、ただの「外部がいぶ接続せつぞくプロトコル」ではない。

Skillの5つの強つよみ

1. チームの方法論ほうほうろんを蓄積ちくせきしやすい
2. バージョン管理かんりとレビューがしやすい
3. 権限けんげん範囲はんいが通常つうじょうより小ちいさい
4. 再現性さいげんせいがより高たかい
5. まず導入どうにゅうして、そのあと拡張かくちょうしやすい

ひとことで言いうと：

Skillはより「標準作業手順書ひょうじゅんさぎょうてじゅんしょ」に近ちかい

MCPは有用ゆうようだが、既定きていの答こたえではない

MCPがより向むいているのは：

• Figma
• Jira / Linear
• Google Drive / Docs
• Slack / 外部がいぶ知識ちしきベース
• リアルタイムデータシステム

それが解決かいけつするのは：

接続せつぞく問題もんだい

であって、

チームの方法論ほうほうろんの問題もんだい

ではない。

MCPのいくつかの現実的げんじつてきな問題もんだい

1. 接続せつぞくは解決かいけつしても、方法ほうほうは解決かいけつしない
2. ガバナンスコストがより高たかい
3. セキュリティ面めんがより広ひろい
4. プロジェクトの暗黙的あんもくてきルールを載のせるのに向むかない

典型的てんけいてきな暗黙的あんもくてきルールには次つぎがある：

• どのディレクトリに触ふれてはいけないか
• どのフィールドを変更へんこうしてはいけないか
• どのテスト群ぐんを必かならず実行じっこうしなければならないか
• どの種類しゅるいの問題もんだいでまずどのログを見みるべきか

これらはAGENTS.mdとSkillに書かくほうが適てきしている。

layout: section

4. 原理げんりレベルを明確めいかくに説明せつめいする

モデルはどうやってこれらの仕組しくみをいつ使つかうかを知しるのか

MCPの原理げんりとは何なにか

MCPはプラグインではなく、1つのプロトコルである。

中核ちゅうかく構造こうぞう：

• host
• client
• server

中核ちゅうかく機能きのう：

• prompts
• resources
• tools
• sampling

動作どうさ方式ほうしき：

1. initialize
2. capability negotiation
3. normal operation

Skillの原理げんりとは何なにか

Skillは1つのprompt文ぶんではない。

それはむしろ、ディレクトリ構成こうせいされたワークフローパッケージに近ちかい：

• SKILL.md
• scripts
• references
• resources

重要じゅうようなポイント：

必要ひつようなときだけ読よみ込こみ、常時じょうじコンテキストを占有せんゆうしない

これこそがSkillが「長大ちょうだいなシステムプロンプト」より効率的こうりつてきである理由りゆうでもある。

CLAUDE.mdとAGENTS.mdの違ちがい

共通点きょうつうてん：

• どちらも永続的えいぞくてき説明せつめいファイルである
• どちらもcoding agentにプロジェクトルールを注入ちゅうにゅうするために使つかわれる

違ちがい：

• CLAUDE.md：Anthropicはより詳細しょうさいな読よみ込こみ仕組しくみを公開こうかいしている
• AGENTS.md：OpenAIはpersistent contextを提供ていきょうすると明言めいげんしているが、実装じっそう詳細しょうさいの公開こうかいはより少すくない

結論けつろん：

どちらもツール呼よび出だし機構きこうではなく、長期的ちょうきてきコンテキストへの入口いりぐちである

layout: section

5. 安全あんぜん、サンドボックス、権限制御けんげんせいぎょ

AIプログラミングは効率こうりつだけを語かたってはいけない

ひとたびagentが次つぎをできるようになると：

• ファイルを読よむ
• コードを修正しゅうせいする
• コマンドを実行じっこうする
• ネットワークに接続せつぞくする

リスクモデルは完全かんぜんに変かわる。

本当ほんとうに議論ぎろんすべきなのは：

• ファイルシステム分離ぶんり
• ネットワーク分離ぶんり
• 最小権限さいしょうけんげん
• 人手ひとでによる確認かくにん
• 全経路ぜんけいろ追跡ついせき可能性

チームが少すくなくとも実現じつげんすべき5つのこと

1. 既定きていで最小権限さいしょうけんげん
2. ファイルシステム境界きょうかいを限定げんていする
3. ネットワークのホワイトリスト
4. すべての越権えっけんを可視化かしかする
5. 高こうリスク操作そうさは必かならず人手ひとでで確認かくにんする

高こうリスク操作そうさの例れい：

• 遠隔えんかくブランチへpushする
• 本番ほんばん設定せっていを変更へんこうする
• 大量たいりょうのファイルを削除さくじょする
• データベース変更へんこうを実行じっこうする
• 実際じっさいの本番ほんばん書かき込こみAPIを呼よぶ

layout: section

6. どう効果こうかを測はかるか、demoだけではない

なぜデモだけを見みてはいけないのか

Demoがしばしば答こたえるのは：

• それが賢かしこそうに見みえるか
• それがそれらしいコード断片だんぺんを生成せいせいできるか

チームが本当ほんとうに問とうべきなのは：

• それが実際じっさいの作業さぎょうを安定的あんていてきに処理しょりできるか
• それがチーム環境かんきょうで再現さいげんできるか
• それがどれだけ手戻てもどりと審査しんさコストを増ふやすか
• それが本当ほんとうに提供ていきょう効率こうりつを上あげるか

外部がいぶbenchmarkで何なにが見みえるか

SWE-benchの価値かち：

• 実際じっさいのGitHub issue
• 再現可能さいげんかのうな評価ひょうか環境かんきょう
• 見みているのは「本当ほんとうに修正しゅうせいしてテストに通とおせるか」

それが示しめせるのは：

AIプログラミングの評価ひょうかはdemo動画どうがや単発たんぱつサンプルだけを見みてはいけないということ

しかし、それは直接的ちょくせつてきに次つぎと同義どうぎではない：

あなたたちのチームはすでに効率化こうりつかできている

チームがより追跡ついせきすべき8つの指標しひょう

• 最初さいしょの実用的じつようてきなpatchまでの時間じかん
• 作業さぎょう完了率かんりょうりつ
• 1回かいでの統合率とうごうりつ
• 人手ひとでによる手戻てもどり時間じかん
• テスト通過率つうかりつ
• レビュー差さし戻もどし率りつ
• ドキュメント同期率どうきりつ
• 安全あんぜんな越権えっけん回数かいすう

ひとことで言いうと：

見みるべきは実際じっさいの作業さぎょう完了かんりょう品質ひんしつであり、生成せいせい速度そくどだけではない

layout: section

7. チームの現実的げんじつてきな導入どうにゅうに戻もどる

私わたしたちの現在げんざいの導入どうにゅう方法ほうほう

• Planモードでまず分解ぶんかいしてから開発かいはつする
• Skill体系たいけいで高頻度こうひんどプロセスを固定化こていかする
• YApi docs-syncでインターフェースの唯一ゆいいつの事実源じじつげんを統一とういつする
• Changelogで変更へんこう履歴りれきを残のこす
• AIが第1段階だいいちだんかいレビューを行い、人ひとが最終さいしゅう判断はんだんをする

目標もくひょうは「AIに人ひとを置おき換かえさせる」ことではなく、

むしろ：

AIを研究開発けんきゅうかいはつプロセスに入いれ、安定的あんていてきな生産力せいさんりょくにすること

私わたしたちのチームで、どのSkillが最もっとも価値かちがあるか

全体ぜんたい共通きょうつうレベル：

• YApi Skill
• ZenTao Skill

プロジェクトレベル：

• ログ Skill
• KV Skill
• データベース Skill

価値かちは「どれだけ高度こうどか」にあるのではなく、

むしろ：

高頻度こうひんどで、安定あんていしていて、再利用さいりようでき、レビューできること

1つの実際じっさいの協業きょうぎょうケース

インターフェース項目こうもくが変更へんこうされたとき：

• バックエンド：コードを修正しゅうせいする
• バックエンド：YApi Skillでdocs-syncをする
• フロントエンド：YApiの変更へんこうを読よむ
• フロントエンドとバックエンド：Planに沿そって接続試験せつぞくしけんを調整ちょうせいする

効果こうか：

• ドキュメントとコードの整合性せいごうせいが高たかまる
• 重複ちょうふくコミュニケーションが減へる
• YApiが唯一ゆいいつの事実源じじつげんになる

チーム導入どうにゅうで最もっとも現実的げんじつてきな順序じゅんじょ

1. まずAGENTS.mdをきちんと書かく
2. 高頻度こうひんど作業さぎょうをSkillにする
3. 必要ひつような外部がいぶシステムだけをMCPに接続せつぞくする
4. 最後さいごにautomationsとmulti-agentを検討けんとうする

この順序じゅんじょは「先にツールを積み上げて、そのあと統治とうちを補おぎなう」より安定あんていしている。

layout: section

8. 最後さいごに4つの言葉ことばだけ覚おぼえる

核心的かくしんてき結論けつろん

1. AIプログラミングはすでに「コード補完ほかん」から「Agentic Coding」へ進すすんでいる
2. チーム導入どうにゅうの鍵かぎはモデル参数ぱらめーたではなく、コンテキストエンジニアリングである
3. 既定きていの優先順位ゆうせんじゅんいはAGENTS.md > Skill > MCPであるべきだ
4. AIプログラミングの評価ひょうかはdemoだけを見みてはならず、境界きょうかい、品質ひんしつ、実際じっさいの研究開発けんきゅうかいはつ指標しひょうを見みるべきだ

参考資料さんこうしりょう

• OpenAI《Introducing Codex》
• OpenAI《Introducing the Codex app》
• OpenAI PDF《How OpenAI uses Codex》
• Anthropic《Claude Code overview》
• Anthropic《How Claude remembers your project》
• Anthropic《Making Claude Code more secure and autonomous with sandboxing》
• MCP 公式こうしき仕様しよう / MCP Architecture
• SWE-bench 公式こうしき Overview

ありがとうございました

議論ぎろんキーワード：

Agentic Coding / Skill / MCP / AGENTS.md / CLAUDE.md