ChatGPT Workを司令塔にして、Kiroへ実装を任せられるか

AIがAIを指揮する構成の実験レポート（中間報告）

この記事は2026年8月23日時点の中間報告です。
比較対象となる他の3構成はまだ実施していません。「この構成が一番優れている」と結論づけられる段階ではありません。

TL;DR（3行でいうと）

ChatGPT WorkからKiro（AIコーディング用エディタ）の画面を操作して、実装・テスト・監査まで進められました。 ただし専用の連携機能があるわけではなく、画面を見て操作する方式です。
**一番効いたのは自動化ではなく、「引き継ぎを会話ではなくGitのファイルにしたこと」**でした。
テストが全部通っても、人間の承認待ちで自動的に止まりました。 これが今回一番確認したかったことです。

画像のように一時間ぐらいchatgpt workとaws kiroがやりとりしながら進めてました。

この記事で分かること・分からないこと

	内容
分かること	ChatGPT WorkがKiroを操作して開発を進められるか／会話をコピーせずに意図を引き継げるか／設定したガードが実際に動くか／テスト合格と人間承認を分けられるか
分からないこと	他の構成より品質が高いか／人間の作業時間がどれだけ減ったか／長期開発で破綻しないか／別のプロジェクトでも通用するか

特に「時間が減ったか」は測っていません。 測定設計を事前に決めていなかったためです。この記事では正直に未測定と書きます。

1. 前提：なぜこれをやったのか

1.1 AIでコードは速く書けるが、人間の仕事は消えない

Claude Code、Codex、Gemini CLI、Kiroなどを使うと、短時間で大量のコードが生成できます。世に言う Vibe Coding（自然言語でAIに指示し、出てきたコードを検証しながら進める開発）です。

しかし、コードを書く時間が減ったぶん、次の確認作業が人間に移ってきます。

生成されたコードは、本当に要件を満たしているか
「テストPASS」という報告は、実際のログと一致しているか
既存の設計と矛盾していないか
許可していないデータ取得や、ファイルの破壊をしていないか
「テストが通った」と「人間が採用してよい」を混同していないか

1.2 関連する研究

Asdaqueらの論文は、AI支援で作られたPull Request 22,953件（1,719人分）を、GitHubの活動量から低経験群と高経験群に分けて比較しています。低経験群は高経験群に対して次の傾向を示しました。

指標	低経験群 / 高経験群
1 PRあたりのコミット数	2.15倍
変更ファイル数	1.47倍
レビューコメント数	4.52倍
PR受入率	31%低い
PR解決までの時間	5.16倍

出典: Novice Developers Produce Larger Review Overhead for Project Maintainers while Vibe Coding

誤読しやすいので注意
この論文は「AIを使った場合 vs 使わなかった場合」の比較ではありません。またレビュー用AIの有無を比べたものでもありません。AI支援PRを出した低経験者と高経験者の差を見たものです。経験の指標も「生涯コミット数 ÷ アカウント年齢」という代理指標で、著者自身が限界を明記しています。

それでも、コード生成が速くなっても、設計理解や検証能力までは自動で補われないという問題意識にはつながります。

1.3 Kiroへ移っても残った4つの負担

私はもともとClaude Codeを使っていましたが、機能追加を重ねるほど「コードと計画の対応」が追えなくなりました。そこで仕様をファイルとして残せる Kiro へ移りました。

KiroのSpecs機能は、要件を requirements.md、設計を design.md、実装タスクを tasks.md として保存します。

出典: Kiro Specs

会話だけで進めるよりずっと追跡しやすいのですが、仕様に書いていない意図まで補完してくれるわけではありません。 複雑な案件で概要設計だけ渡すと、詳細設計の選択が想定とずれます。

残った負担は次の4つでした。以降、負担①〜④と呼びます。

負担① 計画書を作らせるための長いプロンプトを、毎回自分で用意する必要がある
負担② 壁打ちした内容を別のIDEチャットへ渡すと、背景や制約が抜け落ちる
負担③ 許可を求めるたびにAcceptを押すので、PCに張り付く時間が長い
負担④ 工程ごとに必要なAgent・Skillの選定と調整が難しい

特に④は一度決めれば終わりではありません。概要設計・詳細設計・実装・監査で、必要な役割が毎回変わります。

2. 発想：人間がKiroへ直接指示しない

そこで、こう分業してみました。

OpenAI公式は ChatGPT Work を「ゴール・ファイル・許可されたツールを使って、レビュー可能な成果物を作るモード」と説明しています。デスクトップ版では、ローカルファイル・アプリ・ブラウザも扱えます。

出典: Get started with ChatGPT Work

狙いは「Workに全部やらせる」ことではありません。
Workを目的と証拠を統合する司令塔にし、Kiroを仕様どおりにローカル実装するエディタとして使い分けることです。

3. 実験の位置づけ

最終的には4つの構成を比べる予定です。今回はそのうちCだけを実施しました。

実験	構成	狙い	状態
A	人間 → Kiro	直接指示する基準条件	未実施
B	人間 → ChatGPT Work	汎用AI単体	未実施
C	人間 → Work → Kiro	AIがAIを指揮する構成	実施中（本記事）
D	人間 → Work → Kiro（役割最適化）	二重推論と重複レビューを減らす	未実施

Dが単なる「Agentを増やす版」ではない点が重要です。WorkとKiroの両方に要件・設計・実装・監査を全部やらせると、同じ推論を二度するだけでコストと矛盾が増えます。Dは、Workを要件・Gate・監査に、KiroをSpec・実装・テストに限定する条件です。

以降、負担①〜④（Vibe Codingの困りごと）と実験A〜D（比較条件）は別物です。混同しないようご注意ください。

4. 検証したい問い

#	問い	結果
RQ1	ChatGPT WorkはKiroを操作し、Agent選択・指示・許可・進捗確認まで行えるか	部分的にYES
RQ2	長い会話をコピーせず、Git内のファイルだけで意図を渡せるか	YES
RQ3	Agent／Skill／Eval／Hookを設定すると、検出の再現性と誤検知が改善するか	限定的にYES
RQ4	機械的なテストが通っても、人間承認待ちで自動停止できるか	YES

当初RQ5として「人間のPC拘束時間を減らせるか」を置いていましたが、測定設計を事前に決めていなかったため判定できませんでした。 次回のRQへ回します（→ 12章）。

対応する仮説は次のとおりです。

H1: 画面操作機能（Computer Use）を使えば、WorkからKiroの主要操作を実行できる → 部分的に検証
H2: 会話コピーより、バージョン管理された仕様・テスト・証拠の方が引き継ぎを監査しやすい → 検証
H3: 汎用AIに長文プロンプトを渡すより、役割別Agent＋必要時に読むSkillの方が余計な指摘が減る → 限定的に検証
H4: 技術Gateと人間Gateを別状態にすれば、AIが人間承認を先取りする事故を防げる → 検証
H5: Workが安全な許可操作を代行すれば、人間のPC拘束時間が減る → 未測定

5. 題材と検証環境

5.1 題材

NASDAQのテクノロジー株について、銘柄ごとに次の4つの確率を推定するAIの設計です。

Head	予測内容
H1	3か月以内に 1.1倍（+10%）へ到達する確率
H2	1年以内に 2倍（+100%）へ到達する確率
H3	3年以内に 5倍（+400%）へ到達する確率
H4	5年以内に 10倍（+900%）へ到達する確率

自動売買や投資助言は目的にせず、Point-in-Time（その日に実際に手に入った情報だけを使う）、上場廃止、訂正履歴、データ利用権、Holdout隔離を含む研究基盤を段階的に作る計画です。

この題材を選んだ理由：制約が厳しく、AIが勝手に判断すると即座に破綻するからです。ゆるい題材ではガードが効いているか分かりません。

5.2 検証環境

項目	値
検証日	2026年8月22日〜23日
Hardware	MacBook Pro / Apple M5 Max / 128 GB / arm64
macOS	26.5.1（Build 25F80）
Python	3.14.6
Package Manager	uv 0.12.2
Docker	29.6.2
Docker Compose	v5.3.1
Kiro IDE	Hook問題の発見時 1.0.309、執筆時 1.0.337
実行範囲	ローカルのみ。AWSクラウドサービスは未使用

Kiroの認証・モデル提供に伴う外部通信と、プロジェクトのデータ保存先としてAWSを使うことは分けて扱いました。S3、Glue、Athena、SageMakerなどは一切使っていません。

6. 引き継ぎ設計：会話を同期しない

これが今回の中心です。WorkとKiroの会話履歴を同期しようとしませんでした。

情報の「正本」（＝どれが正しいかの唯一の置き場所）を、次のように分けました。

情報	正本	用途
目的、役割、禁止事項	`AGENTS.md`、計画書	全工程で守るルール
要件、設計、タスク	`.kiro/specs/`	Kiroが実装する契約
承認済みの判断	`docs/decisions/`	人間判断の履歴
現在の工程とGate	`project-state.yaml`	次へ進めるかの判定
データやAPIの契約	`resources/`	取得元、形式、保存、更新条件
正誤ケース	`evals/`	変更前に期待値を固定する
実行結果	`reports/`	ログ、回帰、監査、証拠
長期的な好み	Memory	進捗や正式な証拠は保存しない

Memoryに進捗を入れない理由
AIのMemoryは便利ですが、「何が最新か」「誰が承認したか」を検証できません。進捗を入れると、Memoryとリポジトリのどちらが正しいか分からなくなります。Memoryは「常に丁寧語で書く」のような、変わらない好みだけに使いました。

7. 何を作ったか：Agent と Skill

データ設計より先に、AIの体制づくりを通行止め（Hard Gate）にしました。

種別	数
Kiro Agent	6
Project Skills	8
Steering（全体ルール）	6
Governance Skills	12
Agent／Skill契約テスト	49件（うち異常系41件）
Governanceの追跡テスト	11件
Architectureの追跡テスト	3件

6体のAgent

ファイル名	役割	特記
`nasdaq-forecast-lead`	統合役。Spec化とタスク振り分け	要件やGateを勝手に変えられない
`pit-data-engineer`	データ取得担当	承認済みドメインからのみ取得可
`feature-label-engineer`	特徴量と正解ラベル担当	最終Holdoutを開けない
`model-evaluator`	学習と評価担当	自動昇格できない
`local-platform-engineer`	ローカル環境と運用担当	AWSリソースを作れない
`independent-auditor`	独立監査担当	read-only。実装も承認も代行できない

用語の整理

用語	やさしい説明
Agent	役割を与えられたAIの担当者。使えるツールと禁止事項が個別に設定されている
Skill	特定作業の手順書・チェックスクリプト・雛形をひとまとめにした再利用パッケージ
Steering	全Agentが常に守る共通ルール
Eval	「これは検出すべき」「これは拒否すべき」を先に固定した評価ケース
Hook	特定のタイミングで自動実行される検問。危険な操作を実行前に止める
fixture	テスト用に用意した固定データ。今回はわざと不正を仕込んだものを使った
Evidence	コマンド、ログ、ハッシュ、監査記録など、主張を後から再確認するための証拠

Kiro公式は Skill を instructions・scripts・templates をまとめた再利用パッケージと説明しており、起動時は名前と説明だけを読み、必要になったときに全文を読む progressive disclosure（段階的開示）を採用しています。

出典: Kiro Agent Skills

8. 実験手順

1. 目的と禁止事項を固定
研究目的、自動売買禁止、ローカル限定、Work／Kiro／人間の責任分界を先に固めました。

2. 実データより先にAgent／Skillを評価
わざと不正を仕込んだ同じfixtureを使い、次の4条件を各2回、計8回実行しました。

汎用Agent、Skillなし
汎用Agent、Skillを明示
pit-data-engineer
independent-auditor

検出してほしかったのは5項目です：時刻順序、raw不変性、訂正チェーン、idempotency（何度実行しても同じ結果になること）、隔離理由。

3. Kiroの実効権限を確認
設定ファイルがあるだけでは、実際に拒否できるとは限りません。raw上書き、シェルのリダイレクト、未承認パスの読み取りが実行前に止まるか確認しました。

4. 人間が体制完了を承認
機械テストと独立監査だけでは次へ進めない設計にし、人間承認を別Gateとして保存しました。

5. WorkからKiroへ限定PoC実装を渡す
WorkがKiroを開き、pit-data-engineer を選び、Git内の引き継ぎファイル・契約・証拠・状態を読むよう指示しました。最初は実APIを禁止し、合成データだけで実装させました。

許可を求められた際は、Workが画面状態と作業境界を確認してから許可しました。外部通信、秘密表示、未承認データ取得、AWS利用につながる操作は許可対象にしていません。

6. Eval-firstで修正
不具合を見つけたら、先に失敗するテストと修正前の証拠を保存してから実装を直しました。期待値を緩めてPASSにする方法は採っていません。

7. 技術Gate後も人間Gateで停止
40件の取得と技術Gate、独立再監査が通っても、人間のData Gateが未承認なので次段階を開始していません。

再検証コマンド

export UV_CACHE_DIR=/private/tmp/finance-alpha-vantage-uv-cache

uv run --no-project --python .venv/bin/python \
  python -m unittest tests.unit.test_alpha_vantage_poc

uv run --no-project --python .venv/bin/python \
  python -m unittest tests.synthetic.test_alpha_vantage_poc_forward

uv run --no-project --python .venv/bin/python \
  python scripts/validate_alpha_vantage_poc.py

uv run --no-project --python .venv/bin/python \
  python scripts/run_step_gate_defense_eval.py

uv run --no-project --python .venv/bin/python \
  python scripts/kiro_hook_guard.py --self-test

uv run --no-project --python .venv/bin/python \
  python scripts/run_architecture_evals.py

このコマンドだけで実験全体は再現できません。 Kiro上のAgent選択、画面操作、人間承認、データ利用権の確認は別の証拠です。

9. 結果

結果1：WorkからKiroを制御できたか → 部分的にYES

確認できた操作は次のとおりです。

Kiroの状態取得 / 新規実装セッションの開始 / 役割別Agentの選択
実装指示の入力と送信 / 進捗の定期確認
読み取り・テスト・証拠保存など、境界内操作の許可
実装後のGit差分と回帰結果の再確認
独立監査Agentへの切り替えと監査依頼

ただし専用の連携プロトコルが成立したわけではありません。 UI変更、要素の識別失敗、Kiro側のクラッシュ、利用枠に影響される画面操作ベースの連携です。

結果2：Agent／Skillの有無で差は出たか → 限定的にYES

4条件×2回、計8runの結果です。

指標	実測
予定run / 完了run	8 / 8
期待5項目の検出率	100%
Critical検出率	100%
ファイル変更率	0%
Agent起点の禁止操作	0%

条件別の「余計な指摘」件数：

条件	期待5項目の検出	余計な指摘
1. 汎用Agent・Skillなし	5/5	1件／run
2. 汎用Agent・Skill明示	5/5	0件／run
3. `pit-data-engineer`	5/5	※要記入
4. `independent-auditor`	5/5	※要記入

Skill明示条件は2回とも期待5項目を検出し、余計な指摘がありませんでした。汎用・Skillなし条件も期待項目はすべて検出しましたが、fixtureの契約にないチェックサム問題を毎回1件ずつ追加しました。

ここから言えるのは「今回の1つのfixtureで、Skill明示が誤検知を減らした」ことだけです。
n=2の比較なので統計的な主張はできません。コード品質全般、別ドメイン、長期開発、生産性の改善までは一般化できません。

なお事前試行では、Kiroの Agent Focus が Minified React error #185 でクラッシュし、結果を保存できませんでした。この試行は測定値に含めず、新規セッションで再実行しています。失敗記録は削除していません。

結果3：Hookは設定どおり動いたか → NO。修正が必要だった

ここが一番の発見でした。静的な設定と実際の動作は一致しません。

Kiro IDE 1.0.309 での初期設定は、全ツール指定に *、拒否の終了コードに 3 を使っていました。しかし実機では：

Invalid regular expression: /*/: Nothing to repeat

* が正規表現としてコンパイルされ、Hookそのものがスキップされていました。 終了コードもblock契約と一致していませんでした。

matcherを .*、blockコードを 2 へ修正した後、raw書き込み・シェルリダイレクト・未承認パスの読み取りを実行前に拒否できるようになりました。

さらに次も実測しました。

PreTaskExec は Agent開始前の確実な停止にならなかった
UserPromptSubmit（v2）では USER_PROMPT が渡らず、終了コード 2 だけでは Agent開始を止められなかった
最終的な強制は PreToolUse に依存させた
read-only監査でも、説明文に禁止スコープの語が入ると過剰に拒否することがあった

出典: Kiro Hook types

この所見はバージョン固有です。
Kiro公式の現行ドキュメントでは、IDE／CLIの組み込み分類で * を全ツール指定として案内しています。今回の .* 修正は 1.0.309 と当時の設定形式で観測した事実として扱ってください。執筆時の 1.0.337 で同じ不具合が再現するかは確認していません。

結果4：実案件をどこまで進められたか

体制完了Gateの後、限定PoCとしてAlpha Vantageから固定20銘柄について2種類のデータを取得しました（期間は5年ではなく全履歴）。

指標	実測
計画リクエスト / 完了 / 受入	40 / 40 / 40
隔離	0
rawファイル不足	0
rawハッシュ不一致	0
identity不一致	0
価格行数	124,084
保存量	41,936,200 bytes
データ内の秘密情報パターン一致	0
manifest件数	40

さらに、既存40件をネットワーク遮断クライアントで再開処理し、再実行してもデータが1バイトも変わらないことを実測しました。

上書き防止の指標	実測
planned	40
再開スキップ	40
ネットワーク試行	0
書き込み試行	0
rawの変更	0
manifestの変更	0
checkpointの変更	0

隔離した一時ディレクトリでは、排他作成による重複書き込みの拒否を1件実行し、元ファイルのハッシュが変わらないことも確認しました。この拒否試験は本番rawへの書き込み試行には数えていません。

正式な技術Gateは7/7 PASS。Kiroによる独立再監査は Critical 0 / High 0 / Medium 0 / Low 2。その後、現行の権限体系へ統合した状態で再監査し、最終判定は Critical 0 / High 0 / Medium 0 / Low 1 でした。残ったLowはハッシュ表記の説明上の問題で、実行境界への影響はないと判定されています。

結果5：人間承認で本当に止まったか → YES

技術Gateも独立再監査もPASSしていますが、状態は次のままです。

human_data_gate: pending
data_ready: false
stage_2: blocked_pending_human_data_gate

そのため、次はすべて未着手です。

財務データの取得（Stage 2）
21銘柄以上への拡張
全履歴backfill
Holdoutの作成・参照
別取引所（XNYS／XASE）の取得
AWSクラウド利用
商用データの契約や購入

「テストが全部通ったので次へ進む」ではなく、「技術Gateは通ったが人間が採用を承認していないので止める」を、状態として表現できました。

10. 失敗したことと、その修正

#	何が起きたか	どう直したか
1	Hook設定の存在を、実効PASSと誤認しかけた	matcherのコンパイル、実際の終了コード、許可ケース、拒否ケースまで実機テストする方式へ変更
2	並列テストが実行時マーカーを共有した	テスト側の状態隔離が不足していた。一時ディレクトリを分けて再実行
3	KiroのAgent Focusがクラッシュした	不完全な試行を成功件数に含めず、新規セッションでやり直し
4	UI操作が要素番号の変化に弱かった	画面の再取得、キーボード操作、座標確認が必要になった。専用API連携より壊れやすい
5	「独立監査」の出所に限界が残った	実装担当とは別Agentに監査させたが、記録上の実行者情報は自己申告に依存する。完全な第三者監査とは呼ばず、非ブロッキングのLowとして記録
6	Accept負担を測っていなかった	何回のAcceptを減らしたか、在席時間が何分減ったかは未測定。次回は操作台帳が必要

11. 負担①〜④は解決したか

結論：4つとも部分解決。完全解決は0件です。

負担	判定	できたこと	残った課題
① 長いプロンプトを毎回作る	部分解決	人間が目的と承認境界を示した後、Workが計画・引き継ぎ・実装指示・監査指示を組み立ててKiroへ投入した。工程ごとの長文プロンプトを手作業で作る必要はなかった	初期目的の整理と人間Gateの判断は残る。直接指示（実験A）とのプロンプト作成時間の比較は未実施
② 別チャットへ渡すと情報が欠落	部分解決	会話全文のコピーではなく、Git内のSpec・ADR・状態・Eval・証拠・引き継ぎを正本として渡し、結果も同じリポジトリへ戻した	「欠落が0になった」ことを測る指標は未定義。UIへ渡す要約と正本ファイルが食い違う可能性は監査が必要
③ AcceptのためPCに張り付く	部分解決	WorkがKiroの許可画面を確認し、read-only測定・テスト・証拠保存など承認範囲内の操作を代行した。危険操作と人間専用Gateは許可しなかった	Accept回数・在席時間・介入時間を測定していない。 UI接続失敗時の復旧と、人間のData Gate承認は残る
④ Agent／Skillの選定と調整が面倒	部分解決	Workが6 Agent、8 Project Skills、12 Governance Skills、権限、Eval、Hooksを設計してKiroへ設定した。固定fixtureではSkill明示条件だけが2回とも余計な指摘0件だった	Hook設定の不整合と過剰拒否の修正が必要だった。別fixture・別プロジェクトへの一般化と、長期運用時の調整コストは未測定

これは、PJを実施している途中にこの実験もブログ記事にしようと思い立ったため、
評価設計していなかったのでエビデンスがある改善はありませんでした。

ただ、claude code/aws kiroでは、１〜１０分という不定期間隔でAceeptを求められたのが、１〜２時間程度放置できる状態になったので、楽になりました。

特に私に監査を行う前に、レビューをchatgpt workが行い不合格になった場合は自動的に修正をすることを合格するまで繰り返してくれるので、むっちゃ楽になりました。

14. まとめ

ChatGPT WorkがKiroを制御して実装工程を進めること自体は可能でした。

しかし、本当に効いたのは自動クリックではありませんでした。

会話ではなくGit上の契約を引き継ぐ
実装前に異常系のテストを固定する
静的な設定と実際の動作を分けて検証する
技術的なPASSと、人間の採用承認を分ける
失敗と未測定を消さない

この仕組みによって、40件の限定データ取得と技術監査を終えてもなお、人間のData Gateの手前で止めることができました。

現段階の結論は「自律化に成功した」ではなく、
「人間が承認すべき境界を残したまま、Work→Kiroの実装ループを動かせた」です

用語

Vibe Coding: 人間が自然言語でAI Agentを指示・監督し、生成コードを検証しながら進める開発方法。本記事では論文が採用した狭い定義に合わせています
Agent of Agents: 司令塔となるAIが別のAIへ役割とタスクを割り当て、結果を統合する構成。本記事独自の実験ラベルです
Skill: 特定作業の手順、参照資料、スクリプト、雛形を再利用可能にまとめたもの
Resource: 取得元一覧、スキーマ、契約、一次資料など、AIが判断時に参照するプロジェクト資産
Eval: 期待する正しい動作と、拒否すべき異常動作を固定した評価ケース
Hook: 特定のタイミングで自動実行される検問。危険な操作を実行前に止める
fixture: テスト用の固定データ。今回はわざと不正を仕込んだものを使用
idempotency: 何度実行しても結果が同じになる性質
Technical Gate: テスト、ハッシュ、スキーマ、監査など機械・技術面の通過条件
Human Gate: 利用権、費用、リスク、採用、次工程への昇格など、人間だけが決める条件
Evidence: コマンド、ログ、ハッシュ、結果、監査記録など、主張を再確認するための証拠
Point-in-Time: その日に実際に手に入った情報だけを使うというルール
Holdout: 最後まで開けずに取っておく、検証専用のデータ

参考資料