この記事の結論
AIエージェント開発で重要なのは、使うAIの数を増やすことではなく、設計・実装・検査・最終判断の責任を分けることです。この記事では、Netsujoの実運用で使ってきた分業設計を、個人開発や「みやこでIT」のもくもく会で安全に試せる手順へ組み替えます。
ChatGPT、Claude Code、Codexを全部使えば開発品質が上がる、と考えるのは早計です。役割が曖昧なまま複数のAIを直列につなぐと、引き継ぎ、再説明、トークン消費、ブランチの混乱が増えます。
一方で、誰が何を決め、誰が変更し、何を機械的に確認し、どこから人間が判断するかを先に固定すると、AIを増やす意味が出ます。本記事は、Netsujoで公開しているChatGPT・Claude Code・Codexの分業開発を出発点に、「みやこでIT」の読者が自分の小さな開発タスクで再現できる形へ再構成した実践ガイドです。
まず分けるのはAIではなく責任です
結論から言えば、役割分担はツール名より先に決めます。同じAIを複数の役割で使うこともできますが、設計者と実装者と監査者の責任を混ぜないことが重要です。
| 役割 | 主な仕事 | してはいけないこと |
|---|---|---|
| 設計 | 目的、制約、非目的、完了条件を決める | 実装途中で勝手に完了条件を増やす |
| 実装 | リポジトリを読み、必要最小限の変更を行う | 自分で決めた基準だけで完了宣言する |
| 機械検査 | format、lint、typecheck、testなどを実行する | 失敗を解釈でPASSに変える |
| 独立レビュー | 差分と要件を読み、見落としを探す | 同じ変更をその場で書き換えて自己承認する |
| 最終判断 | 証拠を見て採用、修正、破棄を決める | AIの「大丈夫です」を証拠として扱う |
ChatGPTを設計、Claude Codeを実装、Codexを独立レビューに置く構成は、この責任分離を理解しやすい一例です。ツールの優劣を示す組み合わせではありません。
最初にTask Contractを1枚つくる
AIへいきなり「直して」と渡すと、実装中に目的が膨らみやすくなります。最初に短いTask Contractをつくると、作業の境界が見えます。
最低限、次の5項目だけを固定します。
1. 目的：何を良くするのか
2. 対象：どの画面、機能、ファイルを触るのか
3. 非目的：今回は何を直さないのか
4. 制約：互換性、権限、禁止操作など
5. 完了条件：どのテストと観測結果がそろえば終わりか
設計役のChatGPTには、この5項目を曖昧さなく整理させます。重要なのは文章量ではなく、実装者が途中で判断を発明しなくても動ける状態にすることです。
実装者には変更権限を集め、監査者からは外す
Claude Codeなどの実装役には、対象リポジトリを読み、ブランチ上で変更し、必要なテストを実行する責任を持たせます。ここでは一つの作業単位を一つのブランチへ閉じるほうが追跡しやすくなります。
反対に、独立レビュー役は原則としてread-onlyにします。レビュー中に自分でコードを修正すると、「見つけた人」と「直した人」と「直ったと判断した人」が同じになり、独立性が弱くなるためです。
レビューで問題が見つかった場合は実装役へ戻します。修正後は、新しい差分をもう一度検査します。面倒に見えますが、この往復そのものが責任境界です。
AIレビューより先に決定論的チェックを通す
別のAIへコードを読ませる前に、機械で判定できるものを先に終わらせます。
- formatter
- lint
- typecheck
- unit test
- build
- 対象機能の自動テスト
ここで失敗しているのに、別AIのレビューへ進む意味は薄いです。構文エラーや型エラーを高価な推論で探させる必要はありません。
「みやこでIT」の生成AI時代のIT勉強会の価値でも、AI時代には完成した説明を聞くことより、実際に動かして結果の違いを観測する価値が上がっていると整理しました。開発でも同じで、まず実行結果を証拠にします。
Codexを毎回通せば安全、ではありません
独立レビューにもコストがあります。低リスクの文言修正まで毎回複数AIへ回すと、引き継ぎコストのほうが大きくなります。
実務では、変更のリスクでレビュー強度を変えるほうが合理的です。
| リスク | 例 | 推奨する確認 |
|---|---|---|
| Low | 文言、軽微なスタイル、閉じた範囲の修正 | 機械検査＋実装内レビュー |
| Medium | 状態管理、複数ファイル変更、外部API連携 | 機械検査＋別視点レビュー |
| High | 認証、課金、権限、データ削除、デプロイ経路 | 機械検査＋独立レビュー＋人間の明示判断 |
学習目的のハンズオンでは、役割の違いを体験するためLowリスクの課題でも独立レビューまで通して構いません。ただし、実務運用では「AIを何体使ったか」ではなく「リスクに対して必要な証拠がそろったか」で判断します。
3つのAIを使っても、3人の独立した専門家にはなりません
ここは誤解しやすい点です。ChatGPT、Claude Code、Codexと製品名を分けても、それだけで独立性が成立するわけではありません。
独立性をつくるのは、次の条件です。
- 監査者が実装者の結論を前提にしない
- 監査者へ変更権限を渡さない
- 要件と差分を直接読む
- テスト結果を別の証拠として確認する
- 問題があれば実装へ戻し、修正後の状態を再確認する
モデルの違いは補助要素です。責任と権限が同じなら、モデルを変えても自己レビューの構造は残ります。
60分で試すなら、この順番にします
もくもく会や社内勉強会で試す場合は、大きな機能を完成させることを目標にしません。小さな変更を最後まで通し、各段階で何が見えたかを比較するほうが学びを持ち帰れます。
0〜10分：Task Contractをつくる
参加者ごとに、小さく安全なタスクを一つ選びます。設計役のAIへ目的、非目的、制約、完了条件を整理させます。
10〜35分：実装する
実装役へTask Contractとリポジトリを渡します。変更範囲が膨らんだら止め、なぜ必要になったかを記録します。
35〜45分：機械検査を通す
lint、typecheck、testなど、そのプロジェクトにある決定論的なチェックを実行します。失敗した場合は、その失敗自体を共有材料として残します。
45〜55分：別視点でレビューする
独立レビュー役には変更させず、要件、差分、テスト結果を読ませます。指摘が出たら、重要度と根拠を確認します。
55〜60分：結果を持ち寄る
共有するのは「うまくいったプロンプト」だけではありません。
- どこで役割が衝突したか
- どのチェックで止まったか
- AIが勝手に広げようとした範囲は何か
- 独立レビューで何が見つかったか
- 次回から固定したいルールは何か
同じ手順を複数人で試すと、OS、リポジトリ構成、AIへの渡し方、タスクの大きさによる差が見えます。これは一人で成功例をつくるだけでは得にくい情報です。
失敗をプロンプト修正だけで終わらせない
同じ注意を何度もAIへ伝えているなら、その注意は会話の中に残すより、仕組みに移したほうが再現性が上がります。
たとえば「直接mainへ変更しない」「テスト失敗を無視しない」「監査者は書き換えない」といった条件は、毎回のお願いではなく、リポジトリのルール、CI、権限、チェックリストへ移せます。
AIエージェントを使いこなす技術は、プロンプトを長くすることだけではありません。繰り返し起きる失敗を、次回は起きにくい構造へ変えることまで含まれます。
「みやこでIT」で持ち寄るなら、成功例より差分を見たい
「みやこでIT」では、Claude CodeとOpenClawを実際に触り比べるハンズオンや、AIエージェント実践LT会を開催してきました。
次にAIエージェント開発を持ち寄るなら、「このツールが便利だった」で終えるより、同じ小さなタスクを複数人が役割分担で回し、どこで結果が分かれたかを見る形式に価値があります。
AIが書けるコード量は増えています。だからこそ、人が持ち寄る価値は、成功した生成物だけでなく、失敗の条件、判断の境界、再発防止のルールに移っています。
今後のイベントを見る初参加の場合は初参加ガイドも確認できます。
関連記事
生成AI時代のIT勉強会の価値｜京都「みやこでIT」で見えた、教わる場から試す場への変化
生成AIで技術情報を得るコストが下がった今、IT勉強会の価値はどこにあるのか。京都で活動する「みやこでIT」のClaude Code、AIエージェント、AI動画、量子コンピュータの開催実績から、「教わる場」から「実際に試した結果を持ち寄る場」への変化を考えます。
京都府庁旧議場で「AIエージェント実践LT会」を開催しました
2026年5月30日、京都のITエンジニアコミュニティ「みやこでIT」は、京都府庁旧議場にて「みやこでIT特別編｜AIエージェント実践LT会」を開催しました。Claude Code、OpenClaw、Codex、Cursor、ChatGPT、GitHub Copilot、ローカルLLM、マルチエージェント、AIデザインツールなどのAI活用について、京都府庁職員を含む約30名が集まり実践事例を共有した特別編レポートです。
京都のITエンジニア交流会・もくもく会開催レポート｜不思議な宿・佛現寺
京都でITエンジニア交流会やもくもく会を探している方へ。2026年8月、不思議な宿と佛現寺で開催した3企画の違い、会場の雰囲気、参加目的に合う選び方を写真付きで紹介します。
🏷️このカテゴリ：コミュニティ運営
カテゴリ一覧もくもく会・勉強会・交流会の運営ノウハウとケース。
生成AI時代のIT勉強会の価値｜京都「みやこでIT」で見えた、教わる場から試す場への変化
生成AIで技術情報を得るコストが下がった今、IT勉強会の価値はどこにあるのか。京都で活動する「みやこでIT」のClaude Code、AIエージェント、AI動画、量子コンピュータの開催実績から、「教わる場」から「実際に試した結果を持ち寄る場」への変化を考えます。
コミュニティサイトの検索流入、実はBingも効いていた
コミュニティサイトの検索流入はGoogleだけではありません。「みやこでIT」のGA4を2026年7月24日に実測すると、Bing経由の自然検索は直近90日で68セッション、同じ期間のGoogleの約1割にあたる規模でした。記事の公開・更新時にIndexNowで各検索エンジンへ通知する運用を導入済みの状態で観測したこの数字と、AI経由の来訪、そして「なぜ数値を公開するのか」を、因果を断定せずに記録します。
コミュニティサイトをGA4でどう測るか｜「みやこでIT」の計測設計
ITコミュニティの運営サイトで、GA4を使って何をどう測ればイベント運営の判断に効くのか。「みやこでIT」が実際にサイトへ組み込んでいる計測——connpassへの送客、Discordの参加導線、記事の読了とスクロール——を、使っているコンポーネント名まで含めて公開します。7年・157回の開催を続けるコミュニティの実例です。
会員サイトを記事の積み上げに変えた半年で検索クリックが約11倍になった話
会員向けサイトだった「みやこでIT」を、記事を積み上げるサイトに変えて半年。2026年1月の検索クリック17を起点に6月は183へ(約11倍)、表示回数は計測開始の2025年12月比で約35倍に。指名検索に頼らず新規の来訪が増えた過程を、数字の限界も含めて正直に記録します。
勉強会協賛・共催の実例5選｜採用・技術広報につなげる設計
勉強会への協賛・会場提供・共催を、採用・技術広報へどう接続するか。みやこでITの公開実例5件を、確認できた事実・期待できる価値・未計測の成果に分け、再現手順とKPIを解説します。
ITエンジニアコミュニティ15選【2026年版】｜活動確認済み
ITエンジニアが参加できるコミュニティを、全国区9団体・地域6団体の計15団体紹介します。学習・交流・登壇・地域という目的別の選び方、初参加までの4ステップ、よくある質問まで、京都で7年・157回のコミュニティ運営経験をもとに整理しました。全国を網羅する一覧ではありません。掲載順は優劣ではなく、各団体は公式サイト・connpass等の一次情報で活動を確認しています。
京都のもくもく会まとめ｜お寺・町家の開催レポートと探し方
京都のもくもく会をテーマ別にたどれるハブページです。続けて参加する効果、京都のお寺や各地での開催レポート、そして参加方法の詳細記事への入口を一箇所にまとめました。一人参加・初心者歓迎で、157回運営の実績にもとづいて整理しています。
初めてのLT登壇 完全ガイド｜5分で話すネタの選び方・スライド・当日の流れ
勉強会で「LT（ライトニングトーク）に挑戦してみたい」という人向けの完全ガイドです。5分で話すネタの選び方、スライドの構成、当日の流れ、緊張への向き合い方を、157回のイベントで多くの初登壇を見てきた京都のコミュニティ視点でまとめました。参加するだけから、一歩踏み出したい人へ。
✍️この著者：飯田 友広
著者ページ京都を拠点にIT人材・企業・大学・地域をつなぐ京都のITコミュニティ「みやこでIT」を主宰。7年157回の運営からTEMPLEモデルを抽出し、地域コミュニティの実装可能性を研究しています。
生成AI時代のIT勉強会の価値｜京都「みやこでIT」で見えた、教わる場から試す場への変化
生成AIで技術情報を得るコストが下がった今、IT勉強会の価値はどこにあるのか。京都で活動する「みやこでIT」のClaude Code、AIエージェント、AI動画、量子コンピュータの開催実績から、「教わる場」から「実際に試した結果を持ち寄る場」への変化を考えます。
京都で技術相談先を探す方法｜技術顧問・CTO代行の選び方
京都の企業・研究者が技術の相談先を探すときの進め方を整理しました。契約形態を先に決めず「何を判断してほしいか」から分ける方法、相談先9種類の特徴、コミュニティにできること・できないことを解説します。「みやこでIT」と運営会社の関係も明記します。
TEMPLEモデル｜社内・地域コミュニティ設計の6つの観点
京都の「みやこでIT」を7年運営した経験を、Theme・Environment・Members・Persistence・Local・Evolutionの6つの観点へ整理した仮説モデルです。当てはめれば成功する法則ではなく、続いた企画と止まった企画を振り返って、判断に使える問いへ落としました。観点ごとの確認する指標と、当てはめにくい状況までまとめています。
企業のスポンサー協賛でITコミュニティを支援する効果と進め方
採用ブランディング・技術広報の文脈でITコミュニティを協賛する企業が増えています。京都629名・7年157回の運営から、効果・連携メニュー・進め方・失敗パターンを整理しました。
自治体がIT人材コミュニティと連携する方法 — 京都の地域実例から
京都府IT産業振興WG・大正大学京都アカデミア・京都知恵産業創造の森との連携実績から、自治体・地域団体がIT人材コミュニティと連携する形態・進め方・失敗パターンを整理しました。
京都発「みやこでIT」、沖縄CODE BASE OKINAWAで出張もくもく会を開催
2026年5月6日、京都を拠点とするIT共創プラットフォーム「みやこでIT」が、沖縄県宜野湾市のCODE BASE OKINAWAで出張もくもく会を開催しました。3名の小規模試行で、京都と沖縄の地方コミュニティ接続を試みた一日のレポートです。
【ThinkIT寄稿】「みやこでIT」 7年157回の地方コミュニティ運営論
ThinkIT「イベント・セミナー2026」連載第4回として寄稿しました。7年157回のコミュニティ運営経験から、地方ITコミュニティを継続させるために大切な「集客より定着」「反復による信頼構築」「継続可能な形式」の実践知を解説しています。
みやこもくもく会#56 with Digital Nomad Kyoto開催レポート
2026年4月18日、京都・佛現寺で開催した「みやこもくもく会#56 with Digital Nomad Kyoto」のレポート。ヨガ体験と量子力学セッションの特別プログラム、転職ドラフトのクラフトビール提供など、集中と交流が自然に混ざり合う1日を振り返ります。
コミュニティに参加する
京都でITエンジニア仲間を見つけたい方へ
「みやこでIT」では、京都のお寺・町家・大学などで、もくもく会や勉強会を毎月開催しています。
📊 Source data
本記事に登場する「7年・157回・629名」「お寺/町家会場での開催」等の数値は、 「みやこでIT」年次統計レポート(/community-stats) の一次データに基づきます。年別開催数・会場分布・イベント種別構成の集計を公開しています。
LM-4無料配布資料
京都のお寺でコードを書く — 「みやこでIT」参加ガイドブック2026
7年157回運営の実績から整理した、初参加を成功させる実践ガイド
対象：京都のITエンジニア・転職検討者・勉強会初参加の個人
この記事に関連する募集中イベント
申込状況をconnpassで確認8月28日(金)
【となりのAIさん】AIとの関係を持ち寄る、小さな対話会。@京都
本イベントはPeatixでも公開しています。