Claude Code（AI コーディングエージェント）で個人プロジェクトを 2 ヶ月回した。8 週間で Rust 約 6 万行、テスト約 1,200 件、設計ドキュメント約 240 本（行数は追跡下ファイルの総行数、テストは静的カウント）。速度と説明可能性はトレードオフではなかった。
ただし書きたいのは速度の話ではない。AI を開発へ入れると言うと、返ってくる質問はだいたい 3 つに絞られる。
- 勝手に進んで手遅れにならないか
- 品質は担保できるのか
- 何かあったとき、経緯を説明できるのか
どれも「気をつけます」では答えにならない。仕組みで答える必要がある。本記事では筆者が整備したハーネスの要点と、個人プロジェクトでの検証概要を提示する。なお本記事自体の90%は整備済みハーネスにより生成したものとなる。
結論を先に書くと、これは権限設計の問題である。 何を任せ、何を人が持つか。その線をどこに引き、どう機械で保証するか。以下はその実装の記録になる。そして最後に書くが、この線引きはチームの権限設計と同型だった。
上記は整備済みハーネスで「残タスクを確認」と指示した画面例（ボクセルゲーム）。各項目は指示者が提示した要件からハーネスが項目を検出し、記述している。ハーネスは多数の定義済みスキルやスクリプトで構成されている。現在のシステム開発の現場ではこういった運用が一般になりつつある。
決めるのは人 ── 勝手に進まないか（1）
使う機構のほぼ全てを、同じ 3 層で作っている。
| 層 | 担当 |
|---|---|
| 決定論スクリプト | 走査・集計・依存グラフの算出 |
| モデル（AI） | 分類・比較判断・優先順位付け |
| 人 | 価値選択の裁定 |
コードで答えられることを AI に答えさせない。AI は揺らぐので、数を数えさせると回ごとに違う数が出る。逆に意味の判断はコードで書けず、価値の選択はどちらにもできない。
残タスクを整理する場面で見る。
機械が事実を並べる
設計ドキュメントに書いた依存関係をスクリプトが読み、依存グラフ・着手可能なタスク・循環の有無を算出する。ここに AI は関与せず、同じ入力なら常に同じ出力が出る。
AI が判断を添える
その上に AI が比較判断を組み立てる。中立な選択肢は並べさせない。 「A・B・C があります、どれにしますか」は判断の放棄で、専門家の仕事ではない。優劣が付くならまず推奨と根拠を出す。
人が裁定する
そして最後にこう書いて止まる。
どちらを先に閉じるかの順序は示したが、体験を先に埋めるか計測基盤を先に固めるかは価値選択なので裁定はお渡しする。
ここが核心にあたる。AI は技術的な優劣は判定できるが、事業上の優先度は判定できない。にもかかわらず放っておくと「本件では許容」「後続検討に降格」といった裁定を勝手に既決化する。決定の捏造である。
だから規範（エージェントへの指示書）の側で禁じている。裁定は 4 値（今対応・受容・却下・別途起票）で人が下し、AI は推奨と根拠までを出して止まる。進む・止まるの境界が、精神論でなく機構として存在している。
なおプロジェクト憲章としてサービス価値を定義しておくことでエージェントに価値判断の推奨を提示することもできる。
止まる場所が決まっている ── 勝手に進まないか（2）
作業は 8 つのチェックポイントで区切り、4 番目を承認ゲートにしている。実装前に TCR（Task Charter ── 目的・目標・非目標・到達基準）を合意する。それまでコードは 1 行も変えない。非目標を先に決めておくと、途中で範囲が膨らんだときに気づけて、合意を取り直す対象になる。
加えて不可逆な操作は人の手に残している ── 本番への deploy、データベースの更新、外部への送信、共有ブランチへのマージ。AI は実行せず、コマンドを提示して人が実行する。設定の拒否リストで機械的にも塞いである。
それとおもしろいのは、エージェントでタスク詳細を記録しておけば、エージェントが機能設計記述と要求一覧を収集して構成してくれることだ。
品質を運任せにしない ── 品質は担保できるのか
テストを書かせるだけなら簡単で、実際 AI は大量に書く。問題はそのテストが本当に壊れたことを検知するのかにある。
だから完成の定義を変えている。実装をわざと壊し、テストが落ちることを確かめて、元に戻す。 ここまでで 1 つのテストが完成とする。
壊しても落ちないテストは実在し、書いた本人には見えない。実際にやると想定どおりには落ちず、ある作業では守るべき性質を外しても別の理由で同じ形のエラーが出るので緑のまま通るテストが 1 セッションで 3 件見つかった。
同じ発想を仕組みの側にも当てている。危険なコマンドを止めるはずの安全設定が、別記法で書くと素通りすることを実測で見つけ、守りの層ごと作り替えた。「たぶんこう動く」で組んだ保険は、必要な瞬間に効かない。
完了前にはソフトウェア品質特性（ISO/IEC 25010 の品質特性、設計原則群、OWASP など）でレビューをかける。明白な指摘はエージェントが改修まで対応し、設計境界にある指摘は人が裁定する。
記録が残る ── 経緯を説明できるのか
ドキュメントを 3 層で持っている。
| 層 | 中身 | 単位 |
|---|---|---|
| 要求一覧 | 何を実現したいか | プロダクトに 1 つ |
| 機能設計記述 | 各機能の外部仕様と内部設計 | 機能ごと |
| 作業書 | 1 つの変更の計画と作業記録 | 変更ごと |
普通と逆で、一次情報は最下層の作業書にある。上の 2 層はそこから機械的に導出する派生物として保つ。人が実際に書くのは作業書だけなので、そこを正本にすれば同期がずれない。
この形にすると「なぜこの設計にしたか」「なぜやらなかったか」「誰がいつ決めたか」に後から答えられる。AI が書いた部分も人が決めた部分も同じ粒度で残るので、「AI が勝手にやったので分かりません」が構造的に起きない。
実物は公開している。3 層がどう繋がっているかは docs/ を見てもらえれば分かる。
チームへ持ち込むと何が起きるか
ここまでは個人環境の話になる。チームへ持ち込めるかを考えると、1 つ気づいたことがある。
規範を書き溜めるうち、人に対して自分が守ろうとしてきた原則と構造が同じになっていた。実際、同じファイルに人向けの原則が並んでいる。
協力しつつ任せる／実践は育てるより引く（自主性からの体験と自己効力感が成長を促す）
小さくても本人の決定を尊重し結果を引き受けてもらう／失敗しても責めない（安全に失敗できる関係が主体性の土壌になる）
| エージェントへの設計 | チームでの対応 |
|---|---|
| 価値選択は人へ返して止まる | 相手の判断領域を奪わない |
| 決定を捏造しない | 曖昧な合意を「決まったこと」にしない |
| 失敗を大声で報告する | 隠さないで済む関係を作る |
| 非目標を先に合意する | やらないことを握ってから始める |
| 仕組みが効くかを実測する | 精神論でなく事実で改善する |
権限をどこで区切り、何を任せ、失敗をどう扱うか。 相手が AI でも人でも同じ問題だった。違うのは試行の速度で、人相手なら 1 つの試行に数ヶ月かかるものが数日で回る。
ただしチームでの実証は無い。 人には感情もキャリアもあり、「価値選択を返す」が丸投げに見えることもある。同型なのは権限設計の構造で、伝え方は移せない。規範をそのまま読ませるのも非現実的で、機械で強制する部分と口頭で伝える部分の仕分けが要る。
始めるなら承認ゲート（TCR（Task Charter ── 目的・目標・非目標・到達基準）の合意）から入れる。AI の有無に関係なく効くはずで、導入コストも低い。個人環境で効いたものがチームで効く保証は無いので、測ってから広げる。
おわりに
任せる範囲を広げるほど、任せない範囲を明示的に設計する必要が出てくる。数えられることは数えさせない、意味の判断はさせる、価値選択はさせない。この線引きを機構として持たせるのが仕事になる。
そしてその作法は、人と働くときと変わらなかった。AI エージェントはチーム設計の実験場として機能した。確かめられたのはここまでで、チームでの検証はこれからになる。