Research Note

「何をするか」は、かなり固定できるようになっていた

AIにGitHubを操作させるとき、最初は自然言語のルールだけで事故を防ごうとしていた。対象Repository、branch、操作内容、人間の承認範囲を確認し、実行前にもう一度読み返す。そこから、予定している操作を機械可読な状態として残すSurface PlanやAction Intentへ進み、さらに実行するtoolと引数まで事前に固定するCommand Lockを追加した。

狙いは単純だった。AIが直前で別の操作を思いついても、固定済みの計画と一致しなければ止める。「気をつける」ではなく、「実行前の契約」として残すところまで強くした。

それでも、Issueを作るはずがファイルを作った

New-Type-D-Systemの問題量産作業で、Issueを作成する操作をCommand Lockへ保存し、read-backでも正しいtool名を確認した。その状態から実行すると、実際には別のファイル作成toolが呼ばれた。同じ種類の失敗が4回続き、意図しない小さなファイルが作られた。

作られたファイルはすぐ削除し、branchに不要な差分が残っていないことを確認した。その後、tool経路を読み直して新しい実行境界からやり直すと、本来のIssue作成は成功した。さらに別の工程でも、Gitのblob操作のつもりが通常のファイル作成へ流れたり、Issue作成のつもりがPull Request作成へ流れたりする同系統のズレが観測された。

ここで、Guardの守備範囲が見えた

保存されていた予定は間違っていなかった。Command Lockの中身も、実行したかった操作を指していた。それでも違うtoolが選ばれた。つまり、ルールや状態管理は「AIが何を実行すべきか」を固定できても、その契約どおりのtoolしか物理的に通れない実行器まで自動的に作ってくれるわけではない。

これはかなり重要な境界だった。判断層が正しくても、dispatch層で別の操作が選ばれれば事故は起きる。逆に、実行器だけを強く縛っても、その前の計画が間違っていれば精密に間違った操作を通すことになる。「意図」「実際に選ばれた操作」「結果」を別々に観測する必要がある。

事故をゼロにできなくても、被害を残さない仕組みは効いた

今回の失敗では、read-back、対象branchの差分確認、expected-headによる保護、独立レビューなどが別々に働いた。誤操作そのものは起きたが、異常な結果をそのまま次工程へ昇格させず、最終的な制作branchへ不要な差分を残さずに復旧できた。

安全設計を「間違えないAIを作ること」だけで考えると苦しくなる。間違った選択を検出する、実行結果を読み返す、意図と結果が違えば次へ進ませない、復旧後も証拠を残す。こうした層を重ねると、失敗を前提にしながら壊れにくくできる。

次に必要なのは、ルールを増やすことではない

今回の観測だけで、原因を特定のAIモデル構造へ帰属することはできない。少なくとも分かったのは、自然言語ルール、計画状態、Command Lockまで整えても、実行経路がそれらを強制しない環境では別toolが選ばれ得るということだった。

次に見るべきなのは、さらに「絶対に間違えるな」と書くことではない。固定したAction Intentから許可されたtoolへしか進めない実行境界をどこに置くか。その強制を入れたとき、速度や柔軟性とどの程度トレードオフになるかを観測する。AIを賢く説得する研究から、AIが触れるレバーそのものを設計する研究へ、一段進んだ。

遅かったのは、問題を解くAIではなく、問題を取りに行く経路だった

New-Type-D-Systemで20問の学習セッションを試したとき、Question Bankから問題を取り出して出題準備をする部分に時間がかかっていた。問題数が増えるほど、毎回AIが大きなデータを読み、必要な問題を探し、会話へ持ち込む方式は重くなる。

ここで方針を変えた。Question Bankの正本はGitHubに残す。ただし、毎セッションでAIが正本全体を読むのはやめる。ローカルPythonが必要な表示情報だけをキャッシュし、そこから問題を選んでSQLiteへセッションとして固定する。AIは、その固定済みセッションを使って学習者と会話する。

キャッシュには、正答を入れない

高速化のためにローカルへ複製したのは、問題ID、revision、問題文、選択肢など、出題に必要な情報だけにした。正答位置、正答、解説、採点情報は入れない。キャッシュは便利な第二の正本ではなく、revisionと元データのblob identityに結び付いた使い捨ての表示用投影として扱う。

この分離には速度以外の意味もある。出題中のAIが最初から正答を握っている範囲を減らせる。学習者へ見せる情報と、採点するときだけ必要な情報を別の経路にすることで、answer leakageの境界も分かりやすくなった。

124問から20問を固定するまで、約15ミリ秒だった

Easy問題124件をpresentation-only cacheへ置き、全124件の読み込み、20問の選択、SQLiteへの書き込み、read-back検証までを計測した。合計は14.913ミリ秒だった。内訳は、キャッシュ読み込み約1.9ms、選択約1.4ms、SQLite作成・20問書き込み約9.6ms、read-back検証約2.0ms。

この数値は本番サービス全体の応答速度ではない。ローカル環境で、Question Bank取得からセッション固定までのFast Pathだけを切り出したPoCの結果だ。それでも、LLMへ大きなQuestion Bankを毎回渡す必要がないことは十分に確認できた。

20問を最後まで出してから、初めて採点情報を取りに行った

次に、同じpresentation-only cacheとSQLiteを使って20問の連続出題を行った。出題中は採点情報を取得せず、20問ぶんの回答を保持する。20問が終わったところで回答20件をSQLiteへ保存し、read-backで一致を確認してから、GitHub上の正本Question Bankから採点情報を取得した。保存件数は20/20だった。

今回の20問選択はPoCとしてキャッシュ先頭から取ったもので、正式なSession Composerの選択ロジックではない。速さを確認するための実験と、どの問題を出すべきかを決める学習ロジックは分けて考えている。

AIサービスだからといって、全部をAIにやらせる必要はなかった

実験前は、AIがQuestion Bankを読んで、問題を選び、出題し、回答を覚え、最後に採点する流れを一つにまとめやすかった。動かしてみると、その中にはAIである必要がない処理がかなりある。IDの照合、revision確認、問題の固定、回答の保存、read-backは、決定的なコードの方が速くて検証しやすい。

AIに残したいのは、学習者の言葉を受け取り、詰まり方を考え、説明やヒントを調整する部分だ。高速化を進めた結果、AIの仕事を増やすのではなく、AIにしかやってほしくない仕事だけを残す設計へ近づいた。

この後

次は、このFast Pathを正式なCandidate Pool / Session Composerと接続し、問題選択の方針を置き換えずに高速化だけを担当させる。Question Bankのrevisionまたはsource blobが変わったときだけキャッシュを再構築し、正本と高速な実行状態を混ぜないまま、実際の学習セッションで速度と復旧性を見ていく。

「300問作る」は、300回生成すれば終わりではなかった

New-Type-D-Systemでは、G検定向けのEasy問題を実用最低ラインとして300問まで増やすことにした。生成AIに1問作らせるだけなら難しくない。数十問までなら、既存のQuestion Bankを見ながら足りないところを追加する方法でも何とかなる。

問題は量が増えた後だった。次に何を作ればいいかを決めるたびにQuestion Bank全体を読み直し、「この範囲は何問あるか」「まだ薄い概念はどこか」を探し直す。生成より探索に時間がかかり、再開するたびに同じ確認を繰り返すようになった。

最初に、数えている単位そのものを間違えた

Knowledge Graphには、概念同士のRelation Clusterと、問題生成の単位になるQuestion Familyがある。途中でこの数を混同し、140というCluster数をFamily数のように扱って説明していた。再確認すると、current graphのQuestion Familyは141で、そのうちBridgeが17、基礎問題の生産対象になるFoundationが124だった。

ここで、「毎回AIに数え直させる」こと自体が問題だと分かった。正しい数を一度確認しても、次のTurnでまた巨大なBankから復元するなら、同じ誤認と探索コストが戻ってくる。

問題ではなく、Question Familyを生産単位にした

そこでIssueにProduction Ledgerを作り、Foundation 124 Familyを固定の生産単位にした。各Familyへ基礎問題を2問ずつ用意すれば248問。残り52問は、coverageや出題rotationを補うreserveとして後から配る。合計300問という目標を、124個の進捗状態へ変換した。

Ledger上では、各Familyが0/2、1/2、2/2のどこにいるかを追う。次に作る対象はBank全体の再検索ではなく、この状態から決まる。作った後は問題本文を眺めて「たぶん増えた」と判断せず、validationとpromotionの完了までを進捗へ含める。

先に全範囲へ1問ずつ配るSweep方式にした

124 Familyを順番に2問ずつ完成させると、序盤の範囲だけ厚くなり、後半は0問のまま長く残る。そこでSweep 1では全124 Familyへまず1問ずつ配り、Sweep 2で2問目を配ることにした。reserve 52問はその後に回す。

この方式なら、途中で開発が止まっても最低限のcoverageが広く残る。進捗も「いま何問あるか」だけでなく、「何Familyへ到達したか」で見られる。問題数とcoverageを別の指標として扱えるようになった。

Sweep 1は、124 / 124 Familyまで完走した

2026年10月26日、Sweep 1はFoundation 124 Familyすべてへ1問ずつ到達した。独立レビュー、validation、merge後のmain確認まで通し、canonical Question Bankは124 validated Easyになった。まだ各Familyは1/2なのでbaseline完成は0/124。次はSweep 2で2問目を埋めていく。

ここまで来ると、300という数字の見え方も変わる。300問は単なるファイル数ではなく、「124の基礎領域をどこまで均等に覆い、その上で52問をどう補強へ使うか」というProduction Planになった。

大量生成では、AIの記憶より台帳の方が重要になる

生成AIは、目の前の1問を作る能力は高い。しかし大量生産では、「前に何を作ったか」「何が未完了か」「どこまで検証されたか」を毎回会話から復元させると急に弱くなる。人間の制作現場で進行表や在庫表が必要なのと同じだった。

AIにたくさん作らせるほど、プロンプトよりProduction Ledgerの比重が上がる。生成を速くする前に、生産単位を固定し、完了条件を決め、未完了を外に残す。それだけでAIは「毎回全部を思い出す作業」から解放され、生成そのものへ戻れる。

この後

次はSweep 2で124 Familyを2/2へ進める。その後、52問のreserveをどのFamilyへ配るかは、単純な均等割りではなく、coverage、出題rotation、実際の学習結果を見ながら決める。300問を完成させることより、増え続けても全件再読なしで管理できる生産系になるかを見ていく。

学習システムを、問題集ではなく循環として作り始めた

New-Type-D-Systemでは、問題を作るQuestion Foundry、試験条件を持つEXAM、学習者の現在地を扱うBattlefieldを分けて設計した。問題は生成しただけでは通常出題へ入れず、独立した検証を通ったものだけをvalidated bankへ送る。試験側では出題範囲や採点条件を固定し、学習側では弱点、最近の回答、範囲の偏りを使って次の候補を組み立てる。最初の対象はG検定とし、短期の試験対策で実際に使えるところまで持っていくことを目標にした。

契約を動かすと、「つながっているようで、つながっていない」が出てきた

最初のPR群でFoundry、EXAM、Battlefieldの契約を揃えたあと、実際に一周させるE2E確認へ進んだ。そこで、validated questionが実質空でも先へ進める、revision identityが曖昧、conceptの参照が切れていても通る、Session Deltaを削除してもテストが通る、といった穴が見つかった。ファイルやschemaが存在することと、runtimeで本当に依存していることは別だった。

対応では、正解・不正解などの派生状態を外から与えられる形から、rawな回答eventを再計算して導く形へ寄せた。revision、category、concept、validated stateもfail-closedで照合する。独立レビューではanswer aliasの衝突や型の強制変換、存在するだけの配線を反例として壊しにいき、テストが緑でも依存関係が本物とは限らないことを確認した。

回答から次の問題まで、学習ループが一周した

その後はpersistent session、pause / resume、最近の回答や時間軸を使うslow pathを追加し、回答EvidenceからBattlefieldのcoverageとreconnaissanceを更新し、その不足からquestion rotationを経て次のcandidate poolを作るところまで接続した。all-cooldownで候補が空になる、validated candidateが0件になる、同じ回答を再生しただけで状態がもう一度進む、といった境界条件もレビューで見つかり、再実行しても勝手に進まない方向へ修正した。

10月12日には、Question FoundryとBOOTのreconciliation、さらに難易度別Session Composerとreadiness policyの実装へ進んだ。Easy / Normal / Examで見るEvidenceを分け、試験シミュレーションでは未回答を正解率の分母から消さない方向を固めた。設計を文章で置く段階から、実際の回答eventを入れて次の出題が変わる段階へ移り始めた。

AI自身のtool選択ミスが、中央の設計を変えた

NTDの作業中には、本来branchへ行うべき操作を別のGitHub surfaceへ送る失敗も起きた。中央側にはすでにSurface PlanやResource Claimがあったが、正しい予定が保存されていることと、実際にAIがそのtoolを選ぶことは同じではない。さらにPRを作るつもりでIssueを作る誤選択も再発し、Guardが存在するだけでは実行経路を物理的に縛れていないことがはっきりした。

そこで中央では、いきなり強制Gatewayへ飛ばず、まずAIが選んだtoolをEvidenceとして保存し、その後にexpected routeと比較するObservation Phaseへ進んだ。first attemptのblind selectionと、ミス後のretryを別sampleとして扱い、選択精度と回復能力を混ぜない。観測dataもTask Stateの寿命から切り離せる形へ寄せ、将来Phase 2 / Phase 3へ進むかはfield evidenceを見てHumanが判断することにした。

この4日間で変わったのは、「正しい設計」より「正しく動いた証拠」を見ること

NTDでも中央Guardでも、設計書、schema、CIのPASSは必要だった。しかし本当に効いたのは、削除しても通ってしまう依存、空candidate、replay、tool誤選択といった反例だった。仕組みを作ったら完成ではなく、壊し方を考え、その壊し方が通らないことまでEvidenceにする。前の期間に作ったTask StateやGuardを、今度は実運用の失敗で鍛える段階へ入った。

この後

NTDはQuestion Foundryからvalidated bankへ供給できる実運用形と、Session Composer / readiness policyのレビューを進める。中央側はObservation Phaseのfield sampleを蓄積し、tool選択のblind accuracyとrecoveryを分けて見る。強制Gatewayを先に作るのではなく、どの失敗が本当に残るかをEvidenceから判断する。

「止まらず続ける」を会話から状態へ移した

AI Game Studioで試していたLoop Engine v0を一区切りにし、長い作業の現在地をmachine-readableなTask Stateとして中央へ持ち上げた。Human Gateでは止まるが、CIやdeployの待機、途中報告、別AIへの引継ぎは作業終了とみなさない。Issueは目的やAcceptance Criteriaを持ち、Task Stateは現在のstep、再開地点、retry、外部待機を持つ。役割を分けたことで、会話が切れても同じ工程へ戻りやすくなった。

導入後は10のRepositoryへ同じ考え方を接続した。ただしTask Stateを保存するだけでは足りなかった。同時更新にはCAS、開始時には既存taskを調べるStartup Sweep、書き込み前にはResource Claim、同じ阻害要因には3-attempt Guard、STOP / PAUSE後には保存済みnextActionを信用せず現在状態から再計算するreconciliationを追加した。独立レビューで穴を見つけるたびfixtureを増やし、再開や競合を含む状態遷移そのものをテスト対象にした。

Notionは正本ではなく、人間向けの操作盤にした

GitHub IssueをNotionのKanbanへ投影する試験では、1 Project = 1カードより1 Issue = 1カードの方が、現在地、着手待ち、Human確認、完了を把握しやすかった。そこでGitHubやTask Stateを正本のまま残し、Notionをread modelとして扱う共通契約を中央化した。同期は作業開始時とHuman Gate直前を基本にし、Boardの列順のようにAPIで安定して扱えない表示設定は人間側へ残した。

ヒアリングが質問リストからグラフへ変わった

AI Web Studioでは、固定質問を順番に聞くのではなく、案件の目的、規模、顧客、運用頻度、既存資産などから必要な質問だけを選ぶ質問グラフを考え始めた。質問の必要度は全案件数ではなく、その分岐へ到達した件数を母数にして見る。後工程で手戻りが起きたら、単なる修正件数ではなく『最初に何を聞けていれば防げたか』へ戻す。使われない枝は消すのではなく出現条件を弱め、後から要望が増えた場合は必要な質問パックだけを呼び出して全体へ戻す。

この構造はWeb制作のヒアリングだけでなく、案件開始時に必要条件を組み立てるDiscovery / Intake / Requirement Engineにも広げられそうだ。ただし現時点ではWeb Studio内の探索として扱い、一般的なPM基盤として正式採用したわけではない。

ゲーム側はRunの一周がかなり閉じた

Web Game 001では、Maidの能力値をChoice成功率へ接続し、Runで得たLootを持ち帰って装備や家具へ反映し、そのBuild差が次Runの成功率へ返るところまで確認した。CheckpointではCONTINUE / EXTRACTを選べ、Failure時には一時Lootを失う。Stage DifficultyもContent側へ分離し、保存Backendへ進む前にPersistent stateとRun-only stateの境界をserialize / restore contractとして固定した。

ルールを書くだけでは、実行は縛れなかった

この期間で一番大きかったのは、正しいルールやTask Stateが存在しても、実際のtool dispatcherがそれに拘束されていなければ誤操作は起きる、と繰り返し確認したことだった。Issueへ書くべきでない内容をIssueとして作る、branch操作とcontents操作を取り違える、レビューのreconcileより先にmergeへ進む、といった失敗が起きた。さらにSelf-Auditを入れると自分の実装内の抜けを見つけられたが、Self-Audit自体が独立レビューを代替するわけでもない。

そのためMaterial Actionの直前に、current step、execution surface、resource type、operation、Resource Claim、Human Gateを同じ状態から照合する方向へ進めた。Public Showcase用の再現fixtureでも、最終状態だけを確認すると途中の誤状態を後続eventで上書きできることが分かり、各event後のtemporal checkpointとmutation testを追加した。『最後が合っている』だけでは安全性の証拠にならない。

公開フローも実運用で閉じた

Anghel .labのPublication Loopでは、formal sourceをfixed Previewへexact projectionし、人間が確認した同じsourceからProductionへ進む流れを実Publicationで再検証した。Production deploy後も即baseline化せず、実表示とmodal操作の確認を別証拠として取ってから、previous Previewとresulting Productionを親に持つ2-parent baselineへ戻した。Hub、Web、Game、Learning Companionの各入口から中央Publication Loopへ辿れるpointerも正式採用した。

そして定期更新そのものが止まった

最後に、RESEARCH NOTE、LABS、AI REVIEWの定期taskが予定どおり実行されず、一部がscheduled window付近でdisabledになっていたことが分かった。内部の停止理由までは取得できず、10月5日のplatform障害との相関はあるものの因果は未証明。幸いResearch Telemetryのappend-only eventと各Repositoryの正本が残っていたため、過去に実行したことにせず、最後の正常状態から現在までをcatch-upとして再構築できた。監視対象にしていた仕組みが止まり、その監視記録で監視を復旧する、かなり中央監査室らしい締めになった。

この後

中央側ではTask Stateを持つだけでなく、実際のaction authorizationまでdispatcherへつなぐ方向を続ける。Web Studioは質問グラフを実案件で検証し、Game StudioはPersistent ProgressionからSave / Resumeへ進む。定期taskについては再作成したscheduleが次回正常に走るかを観測し、再びpauseする場合は別の運用経路を検討する。

ゲームを作る前に、作り方を作り直した

AI Game Studioでは、Unityを必須にせずWebで先にゲーム性を検証する制作レーンを追加した。最初の企画はAIレビューを通ったが、人間が想定していた『ラン前に装備や家具を組み、持ち帰れるかを賭けて進む』遊びとずれていたため、Human Reviewから企画をリセットした。レビューを通過したことより、意図と一致していることを優先した。

その後は画面より先にSeed再現可能なHeadless Coreを作り、Run、Loot、Checkpoint、ChoiceをUIなしで検証した。Browser playable、11枠Equipment、6×6 Furniture、7基礎Parameterと派生能力、Loot品質、再利用Engineへ段階的に広げた。ゲーム固有ContentとRun Engineを分離したことで、次のWeb Gameへ持ち出せる境界も見え始めた。

実案件を、再利用できる工程へ変える実験を始めた

Content Foundryを新しく立ち上げた。単発のHTML制作やCMS更新を自動化するのではなく、入力を正規化し、Execution Planを作り、変更前検証、実行、read-back、Human Reviewまでを一つの処理系として残すことを狙っている。

最初の検証では10ページのHTML一括生成とWordPressの部分更新を通し、その後Review ContractとVisual Evidence生成まで進めた。PCとモバイルの20枚のスクリーンショットを自動生成した最初の試行では全ページの横スクロールを検出し、fixture修正後の再実行でoverflow 0、broken image 0まで確認できた。

Previewは『見える場所』ではなく『何を見たか』になった

Anghel .labでは、LABS、WORKS、RESEARCH NOTE、AI REVIEW、HUMAN RAMBLINGSの確認先を一つのshared fixed Previewへまとめた。ただURLを一つにするだけでは、Preview後に別branchで内容を作り直すと『人間が確認したもの』と『本番へ入れるもの』がずれる。そこでformal sourceを先に確定し、そのexact stateをPreviewへ投影し、承認後も同じsourceからProductionへ進む流れへ整理した。

Cloudflare側もProduction branchとshared fixed Previewだけを自動deploy対象にし、Build Watch Pathsと組み合わせた。branchで絞り、pathでも絞る二段構えにしたことで、同じmonorepoの無関係な更新から公開環境を切り離せるようになった。Web GameのWORKS掲載も、ゲームごとの専用ページを増築するのではなく、共通Game CMSへ寄せた。

Telemetryにも入口と失敗隔離が必要だった

Research Telemetryでは、producerが直接canonical logへ触らず、inboxで受け、schema validationを通ったものだけをpendingへ昇格し、append gatewayでevents.jsonlへ到達させるairlockを実装した。最初はbotからbotへのworkflow relayが成立せず、validateとappendを同じserialized workflowへ統合してE2Eを通した。

同時に、複数AI Reviewerの成果物名、native document、Drive上の保存場所、scheduled pollingなども中央ルールへ整理した。便利な新ルールを一行足しただけでPreview順序の解釈が逆転する失敗も起き、既存ownerがある場合は追記より節全体のrewriteを優先する、という自分たちの設計ルールを自分たちで踏み直すことになった。

Career Agentでも、勝手に直さない仕組みを足した

求人評価ではPipeline 0.30に対してRuntime TemplateとValidatorのversion pinが0.29のまま残る同期漏れを実運用中に検出した。周辺pinを同期したうえで、以後はversion mismatchを見つけても自動補正や旧版継続をせず、Human Gateへ戻すようにした。自動化を強くするほど、『直せそうだから直す』を抑える仕組みが必要になる。

この期間で見えたこと

AIに何かを作らせる工程はかなり速くなった。その分、問題は制作そのものから、状態、証拠、レビュー対象、公開経路、復旧手順へ移っている。成果物を作るAIと、仕事を安全に完走させる仕組みは別物だった。今はその二つを一緒に設計している。

この後

Web Game 001は能力値がChoice成功率へ影響するところまでRunを閉じ、Game CMS / Development Logの運用を実開発と一緒に回す。Content Foundryは実案件に近い入力と外部副作用を増やし、Review Contractがどこまで再利用できるかを見る。中央側ではshared PreviewとResearch Telemetryの定期運用を観察し、止まった時だけ仕組みを直す。

うまいプロンプトを書けば、AIはちゃんと働く？

少し前まで、生成AIの使い方といえば「良いプロンプトを書こう」が中心だった。

役割を決める。手順を番号で書く。最後に確認させる。出力形式まで指定する。短い仕事なら、これでかなりうまくいく。

ところが、AIに長い仕事を任せ始めると妙なことが起きる。

「Aを保存して、Bを調べて、Cを直して、最後に報告して」と頼んだのに、Aを保存したところで「完了しました」と帰ってしまう。

もちろん、本当に記憶から消えているとは限らない。元の依頼はまだ会話の中に残っている。それでも、途中の成功が強い区切りになって、仕事全体が終わったように振る舞うことがある。

私はこれを、ひとまず「カラスの途中帰宅問題」と呼んでいる。

問題は「記憶」より「未完了を状態にしていないこと」だった

最初は単純に「保存を忘れるな」と考えた。

そこで保存工程を強くした。先に保存し、書けたか読み返し、確認してから次へ進むようにした。

すると別の問題が出た。

保存は完璧になった。でも、その後に頼まれていた本題を忘れて帰った。

ここで見え方が変わった。

問題は保存ではない。AIに「まだ何が残っているか」を明示的な状態として持たせていなかったことだった。

人間なら、頭の中やメモ帳に「あとBとCが残っている」と置いておける。長いソフトウェア開発ならIssueやタスクリストに残す。ところがチャットAIでは、依頼文そのものを手順書とタスク管理表の両方として使いがちだ。

それで短い仕事は回る。でも、ツール利用、保存、検証、人間確認、別Repositoryの調査などが増えると、途中工程それぞれが小さな「完了」に見えてくる。

そこで、依頼全体を別に保持する REQUEST_LEDGER という考え方を入れた。

たとえば、

・Aを保存する

・Bを調べる

・Cを修正する

・最後に報告する

を最初に別々の未完了項目として持つ。

Aが終わったら「仕事が終わった」ではなく、「Aが終わった。次は何がpendingか」を見に戻る。

Anthropicは、定型的な仕事ではLLMとツールを決められた経路で動かすWorkflowと、LLM自身が手順やツール選択を動的に決めるAgentを分けている。OpenAIのAgent設計ガイドでも、Agentはworkflowの現在状態を見ながら、完了判定や失敗時の引き継ぎを行うものとして説明されている。

つまり、AIに長い仕事をさせるほど、「うまい文章を書く」だけでなく「仕事の状態をどう管理するか」が重要になる。

ただし、全部をIssueにしたら今度は遅い

ここで別の罠がある。

では毎回すべてのタスクを外部ファイルやIssueへ保存すればいいのか。

それも違う。

「この求人どう？」 「2と4だけもう少し調べて」 「この文章を直して」

のような数分で終わる仕事まで、毎回YAMLを書き、状態を永続化し、完了確認を回していたら、タスク管理のために仕事をすることになる。

大きい開発なら、すでにIssueがその役割を持っている。手順、依存関係、未完了項目、再開地点を外に残すのは自然だ。

一方、短い会話では、そのTurnの中だけに軽いLedgerがあればよい。

私の中では、今のところ次のように考えている。

・数分で終わる単発作業は、その場だけの一時的なタスク一覧

・複数Turnにまたがる、分岐が多い、再開しそうな作業は、少し強い継続状態

・長期開発、複数AI、複数Repositoryにまたがる仕事は、Issueや外部の作業状態へ昇格

重要なのは「全部保存する」ことではない。

仕事の寿命に合わせて、状態管理の重さを変えることだと思う。

タスク分解は、細かくすればいいわけではない

もう一つ気づいたことがある。

AIに長い仕事を任せるなら、タスク分解は確かに効く。

ただし、間違った問題設定を10個のきれいなサブタスクに分解したら、できるのは「精密な間違い」だ。

同じ不具合が何度も出る。同じガードを複数ファイルへ足し始める。直したら別の場所で同型の事故が起きる。

そんな時は、タスクをさらに細かくする前に、「そもそも一段上の構造問題ではないか」を確認した方がいい。

そこで中央の監査役には、同じ失敗が再発した時、追加patchの前に一度上から全体を見る役割を持たせた。

毎回大改造をするためではない。局所修正で十分なら、そのまま戻る。

「賢く考えろ」と祈るのではなく、「二度同じ穴に落ちたら一度地図を見ろ」と役割にしておく。

Prompt Engineeringの次に必要だったもの

今回の流れを振り返ると、私の中ではこう変わっていった。

最初は「良いプロンプトを書けばいい」。

次に「仕事を分解すればいい」。

その次に「未完了を状態として持たないといけない」。

さらに「その状態をどこまで外に保存するかは、仕事の大きさで変える」となった。

Anthropicも、Agentは高い性能と引き換えにコストと遅延を増やすため、まず単純な方法から始め、必要な場合だけ複雑さを増やすことを勧めている。

ここはかなり重要だと思う。

AIを安定させるために、何でも巨大なAgent基盤にする必要はない。

短い仕事なら良いプロンプトで十分なことも多い。

でも、仕事が長くなり、道具を使い、途中状態が増え、別のAIや人間まで混ざるなら、もう「忘れるな」と書くだけでは足りない。

カラスに覚えさせるのをやめた

最終的に変わったのは、AIへの期待の置き場所だった。

以前は、AI自身が最初の指示を最後まで覚えていてくれることを期待していた。

今は違う。

覚えていることを前提にせず、未完了が残っていれば戻れる構造を作る。

人間でも、複雑なプロジェクトを記憶力だけで回したりはしない。

Issueを書き、チェックリストを作り、状態を残す。

AIも同じだった。

カラスに「忘れるな」と大声で言い続けるより、帰宅しようとした時に「まだBとC残ってます」と返してくれる仕組みを作った方がいい。

プロンプトの工夫が不要になったわけではない。

ただ、長い仕事ではその先に、仕事そのものを管理する設計が必要だった。

参考

・Anthropic, “Building Effective AI Agents” (2024)

・OpenAI, “A practical guide to building AI agents”

・Anthropic, “Effective context engineering for AI agents”

AIを導入した。さて、何に使う？

生成AIを社内で使えるようにしたものの、実務ではほとんど使い道がない。今回は、そんなAI導入について考えてみる。

知り合いの愚痴や読んだ記事が混ざっているが、ここでは、そうした話に共通していた構図だけを取り出して考えてみたい。

利用前には使用ルールの説明会があり、それを受けていない人は使ってはいけない。プロンプトの例も用意されている。

ここまでは分かる。

問題はその先だ。

安全性がよく分からないので、社内のDriveにはつながない。メールにもつながない。開発中案件のソースも渡さない。ローカルにある業務ファイルも入れない。

それでも「有効に使ってください」と言われる。

すると利用は、画像を作ってみる、小説を書かせてみる、一般的な質問をする、といった方向へ寄りやすい。

仕事で使うとしても、案件の詳細は渡さず、うまくいかない部分のコードだけ切り出して質問する程度になる。

便利ではある。

でも、これで仕事が大きく変わる感じはしない。

木の一部だけ見せて、「森全体をどう直せばいい？」と聞いているようなものだからだ。

「AIを配る」と「AIに仕事をさせる」は別だった

こうした話を見聞きしていると、AI導入には少なくとも二つの段階があるように思う。

一つは、社員がAIへアクセスできるようにすること。

もう一つは、実際の仕事の中でAIが安全に役割を持てるようにすること。

前者だけなら簡単だ。

アカウントを配り、使用ルールを説明し、プロンプト例を渡せばよい。

でも後者には、もう少し設計がいる。

・何の仕事ならAIへ渡してよいのか

・どのデータまで見せてよいのか

・どこから先は人間確認が必要か

・AIが参照すべき資料はどこにあるか

・失敗した時にどこへ戻すか

・成果が出ているかをどう測るか

これらがないまま、「良いプロンプトを書いて活用してください」と言われても、使い方を社員一人ひとりが設計することになる。

全社員をプロンプト職人にするのは、かなり無理がある。

プロンプトを配るより、役割を組み込む

たとえば人事なら、求人票を確認する時に見るべき項目がある。

営業なら、提案前に過去案件や顧客情報を確認する。

開発なら、変更前に既存コードや影響範囲を見る。

それなら毎回社員が「AIにどう聞けばいいだろう」と考えるより、AI側にその役割を最初から持たせた方がいい。

ユーザーは普通の言葉で依頼する。

裏側では、必要な資料を取り、確認項目を補い、危険な操作だけ人間へ返す。

私が今作っている中央監査の仕組みも、その考え方に近い。

「ツギハギになっていないか」 「元の依頼を落としていないか」 「その操作をしてよい権限があるか」

を、人間が毎回プロンプトに書かなくてもAI側の役割として持つ。

AIを使う人を全員AI専門家にするより、AIを使う仕組みの方を賢くする。

その方が現実的だと思う。

ただし、全部をAgentにすればいいわけでもない

ここで別の極端に振れると、「では全員に強力なAgentを配ろう」となる。

これも危ない。

チャットAIと、ファイルを書き換えたりShellを実行したりするCoding Agentでは、できることも事故の大きさも違う。

AnthropicはClaude Codeの権限確認について、ユーザーが約93%の許可要求を承認していたと報告している。確認が増えすぎると、人は一つ一つをよく見なくなる。そこで同社はsandboxや自動判定を使い、そもそも実行できる範囲を狭くする方向へ進めている。

つまり「人間が全部ちゃんと確認すれば安全」だけでも足りない。

誰に、どの道具を、どの権限で渡すかまでが導入設計になる。

全員に最強のカラスを放つより、仕事内容に合わせて鳥かごの大きさを変えた方がいい。

そして次に来るのは、カラスの餌代

Agentは便利だが、無料ではない。

一つの依頼の中で、計画、検索、ツール利用、再判断、検証、再試行を何度も行えば、そのたびにモデル利用料と待ち時間が増える。

Anthropicも、Agentは性能と引き換えにコストと遅延を増やすため、まず単純な方法から始め、必要な場合だけ複雑さを増やすべきだとしている。

実際、Coupaの事例では234のAgent、150超の本番Workflow、週15,600件超の自動タスク、月3〜5Bトークンという規模まで拡大している。そのため、仕事の難しさによってモデルを振り分ける仕組みを使い、あるAdaptive Model Selectionの用途では1セッションあたり78%のコスト削減を報告している。

規模が大きくなると、「AIを使うかどうか」ではなく、

・この処理にLLMは必要か

・毎回いちばん強いモデルが必要か

・同じ長い文脈を何度も送る必要があるか

・5回再試行する価値があるか

・3つのAIに同じレビューをさせる必要があるか

という話になる。

人件費削減のためにAIを入れたら、次はAI経費削減会議が始まる。

少し輪廻を感じる。

AI導入は、従業員のキャリアにも影響する

もう一つ気になることがある。

AIを積極的に仕事へ組み込む企業と、人力中心で進める企業では、数年後に従業員が持っている経験そのものが変わるのではないか。

人力中心の方針が悪いとは思わない。

ただ、片方では、

「AIと一緒に業務を組み直した」 「どこをAIへ任せ、どこを人間が持つか設計した」 「AIを使って成果を出した」

という経験が毎日の仕事で積み上がる。

もう片方では、会社の制約によって、その経験を積む機会そのものが少ないことがある。

将来、AIと協働した経験が普通の職務要件になった時、本人が怠けていたわけではないのに、所属企業の導入方針によってキャリア差がつく可能性がある。

AI導入は、経営側から見れば生産性施策だ。

でも従業員側から見れば、職業訓練環境でもある。

ここはもう少し議論されてもいい気がする。

AIを導入するなら、仕事も一緒に設計する

AIを配るだけなら簡単だ。

逆に、安全を考えて全部閉じるのも簡単だ。

難しいのは、その間にある。

安全な範囲で業務へ接続し、役割を決め、必要な情報を渡し、人間確認を残し、費用も管理する。

つまりAI導入で必要なのは「利用許可」ではなく、仕事の設計なのだと思う。

社員へ「プロンプトを工夫してください」と言う前に、会社側が「このAIには何の仕事をさせるのか」を決める。

カラスを配るなら、止まり木だけでなく、仕事も用意する。

そうでなければ、社員はしばらく遊んでみた後にこうなる。

「で、これ何に使うの？」

参考

・Anthropic, “Building Effective AI Agents”

・Anthropic, “How we built Claude Code auto mode: a safer way to skip permissions”

・Anthropic, “How we contain Claude across products”

・Microsoft Research, “The Effects of Generative AI on High-Skilled Work”

・AWS, Coupa Success Story

GitHubの時刻を並べてみた

最近、新しいRepositoryを作ってから作業が動き始めるまでが妙に速くなった気がしていた。感覚だけでは分からないので、Repositoryのcreated_at、最初のcommit、Foundationを作ったPull Request、最初に使える状態へ到達した記録を時系列で並べた。ここで見ているのは主に経過時間で、作業工数ではない。

最初は、開発の前に開発方法を作っていた

AI Game StudioのRepositoryを作ったのは7月1日だった。最初の実質的なDocs追加までは約15日。Project Overview v1.0までは約27日。AIOSの文書体系が承認済みのFoundationとしてまとまったのは8月26日で、Repository作成から約55日18時間だった。この時期はゲームを作る前に、AIがどう役割分担し、どこで人間へ戻り、何を正本として読むかという開発OSそのものを作っていた。

Web Studioで、単位が週から時間へ変わった

AI Web Studioは8月28日14時53分ごろに作成し、約2時間後にはStage 1の静的フロント制作基盤、参照実装、品質検査までmainへ入った。AIOSで考えていた入口、承認境界、状態管理をそのまま複製したわけではないが、『AIが迷わず作業へ入るために何を先に決めるか』という考え方は持ち込めた。ゼロからルールを発明する時間が減った。

9月1日に作ったWeb Workspaceでは、数分で最初の案件を移した。ただしこれは成功例として数えなかった。移したデータが別のサンプルだったからだ。誤移行を削除し、正しい案件を取り込み、品質確認、PCと390×844の表示確認、Cloudflare Pagesのテスト公開まで確認できたのはRepository作成から6時間24分以内だった。速さを測るなら、最初に何かcommitした時刻ではなく、実際に使える成果へ届いた時刻を見る必要がある。

速くならないRepositoryもあった

AI Learning Companionは9月5日にRepositoryを作ったが、Foundationがmainへ入るまで約2日15時間かかった。Small Simulation stable v1までを見ると約6日だった。ここだけを見れば、Web Studioより遅い。対象が違えば、必要な検証も違う。特に学習支援では、データ境界や安全性、Synthetic validationを先に分ける必要があり、単純な制作速度とは比べられない。この遅い例を残しておかないと、『何でも速くなった』という都合のいい話になってしまう。

9月中旬、作業場そのものが部品になった

9月14日にAI Telemetry Hubを作った時は、Repository作成から7分24秒で中央Hub architectureが入り、その後20分ほどでRegistry、schema、週次レビュー、Governanceの骨格が並び始めた。同じ日の夜にField Ops AIDX Labを作ると、約2時間34分でStructured Bootstrap、Decision Lifecycle、Evidence Discipline、Effect Controlを含むFoundationがmainへ入った。ここではAI Web Studioで育ったMarkdownとYAMLの責務分離やdependency routingを、Field Ops向けに組み替えている。

さらにその途中で最初のField Ops Project Repositoryを作った。作成から約1時間26分でProject Foundation、約2時間14分で最初のDiscovery整理、約9時間40分でEvidence不足を明示したTo-Be / MVP候補モデルまで進んだ。MVPを完成させたわけではない。むしろ、確認できていないものをCandidateのまま止める仕組みまで含めて短時間で立ち上がったことの方が重要だった。

3つの速度を混ぜない

今回の時系列を見ていて、少なくとも3種類の速度があると分かった。新しいテーマをRepositoryとして始める間隔。Repositoryから運用可能なFoundationまでのBootstrap latency。Foundationから最初の使える成果までのValue latency。この3つを全部まとめて『開発速度』と呼ぶと、何が変わったのか分からなくなる。

これは作業時間の計測ではない

数字には睡眠、食事、別のRepository、仕事や日常の用事も普通に入っている。GitHubのtimestampから分かるのはwall-clockの経過時間であって、何時間キーボードに向かっていたかではない。逆に言えば、そのノイズを含んだままでも、最初の世代では週単位だったFoundation立ち上げが、後のRepositoryでは時間や分の単位へ縮んでいることは確認できた。

消えたのは、毎回ゼロから始める時間だった

一番大きく変わったのは、コードを書く速度ではなかった。新しい問題に出会うたびに、ルール、入口、承認境界、状態管理、証拠の置き場を毎回考え直す時間が減った。Structured Bootstrap、Human Gate、dependency routing、Telemetryが別々のRepositoryで試され、使えたものだけが次へ移るようになった。

しかも流れは一方向ではなくなった。後から作ったField OpsのStructured BootstrapがLearning Companionへ戻り、AIOSのRisk分類やTelemetry HubのHuman Gateも同じ基盤へ組み込まれた。Repositoryが増えただけではなく、各Repositoryで作った部品が別の研究へ戻るネットワークになり始めている。

この後

今後もRepository作成時刻、Foundation到達、最初の実用成果を同じ基準で残していく。速くなったかどうかだけではなく、どの仕組みを再利用した時にBootstrap latencyが縮んだのかを見る。逆に時間が伸びたRepositoryでは、何を新しく考える必要があったのかを残す。速度を競うためではなく、どこまでが再利用でき、どこから先は毎回ちゃんと考え直す必要があるのかを見るための記録にする。

画面は、触るとすぐ予定を裏切る

AI Learning Companionでは、設計した学習画面をスマートフォンで実際に触る確認を続けた。初回Tutorialを通してみると、操作を覚えるための説明と、普段の学習画面に常駐させる説明は分けた方がよかった。そこで初回だけ操作を教え、通常画面は軽く保つ方向へ整理した。

Hintについても、AIへ何でも渡すのではなく、問題、作業盤、選択中のチップ、本人が入力した質問、直近の操作など、観測できた事実だけをRequest Contextとして渡す形を実機で確認した。盤面全体から聞く場合と、特定チップから聞く場合を分けても、同じ契約で扱えることが分かった。

案件ごとの工夫を、案件だけのものにしない

同じ頃、Learning CompanionのRepository基盤も見直した。別の研究で使えるようになっていたStructured Bootstrap、人間向けの説明と機械向けの契約の分離、依存関係から必要な資料だけ読む入口、Human GateやPreviewの境界を、この案件向けに組み替えた。機能試作と基盤変更を同じbranchで混ぜないことも決めた。

Field Opsでは、答えを出すより先に止まる場所を作った

Field Opsの最初の案件では、30日、90日、180日という段階計画を作った。ただし日付が来たら自動的に次へ進む計画ではない。確認結果によって継続、方針変更、保留、中止を選べるようにした。

初期分析でも、一つの仮説だけを正解にしなかった。必要な現物、実案件、データ、変更履歴、権限情報が足りなければ断定しない。対抗仮説を残したまま、次に何を確認すれば差がつくかを先に整理した。作る前にEvidenceの不足を見えるようにする方が、後から大きく戻るより安い。

安全ルールも、失敗した時に具体的になった

GitHub操作では、branchを作るつもりが一時的なIssueを作ってしまう失敗も再発した。すぐCloseできて成果物への影響はなかったが、『書き込み先を確認する』だけでは足りない。Repository、branch、対象resource、実行するoperationまで書き込み直前に照合する必要があると分かった。

この期間で変わったこと

個別案件で問題を直して終わる場面が減ってきた。スマートフォンで見つけた操作の摩擦、Field Opsで必要になったEvidenceの停止線、Repositoryで再発した操作ミス。それぞれを次の作業でも使える入口やGuardへ戻すようになった。

この後

Learning Companionは実機での操作確認を続け、学習支援ロジックと画面の境界を詰める。Field Opsは仮説を実データで確認できるところまで進める。共通化した仕組みは、別Repositoryへ持ち込んでも同じ失敗を減らせるかを見ていく。

公開した後の方が、運用の穴がよく見えた

Anghel .labを正式公開した翌日、最初のCMS更新としてWORKSを1件追加した。ここでまた画面サイズの問題が出た。確認用ブラウザから1920×1080や390×844を正確に作れない。以前の最終確認では固定サイズのVerification Harnessで回避していたので、今回はその方法を共通のフォールバックとして再利用した。うまくいった方法を、その場限りの裏技で終わらせず、次回も呼び出せる手順へ戻す必要があった。

同じ更新で別の問題も出た。Anghel .labだけを変更したのに、同じworkspaceにある別のCloudflare Pages案件まで不要なPreview buildを始めた。前にも似た問題を直していたが、新規案件の初期設定へ組み込まれていなかったので再発した。Build Watch Pathsを案件ごとの手作業ではなく、新規接続時に必ず確認する項目へ昇格し、対象内変更ではbuildする、対象外変更ではbuildしない、の両方を実際に確認した。

標準検査を通った画面にも、まだ穴があった

公開済みのAnghel .labを別AIに見てもらうと、モバイルの一覧ナビが閉じたまま操作できないケースと、LABSのcurrent位置計算が不安定になり得る点が見つかった。QualityもFinal Verificationも通っていたので、『検査が通った = もう見るものがない』ではない。別視点のレビューとHuman Gateでしか拾えない表示回帰がある。修正後はスマートフォンでの横揺れまで含めて再確認し、検証工程そのものをAI Web Studio側へ戻した。

会話の脱線を残そうとしたら、記録の仕組みまで作ることになった

この2日で、Anghel .labにHUMAN RAMBLINGSを追加した。人間とAIの会話から、発想の飛躍やツッコミ、勘違いまで記録する。ただし、実発言と再構成を混ぜない。Telemetryの記録と公開CMSも分ける。候補、採用、公開承認も別にする。軽い読み物を作る話だったのに、結局は『どこまで事実として扱ってよいか』の境界設計になった。

記録経路自体でも失敗した。DIALOGUEという新しい記録用途をルールへ追加したのに、append gateway側の許可リストが古いままでqueue全体が停止した。逆に言えば、途中まで正本へ書き込まずfail-closedで止まったので、壊れ方としては正しかった。さらにTelemetry作業中のツール選択ミスで空のIssueを作ってしまい、書き込み前にrepository・branch・pathを確認し、Telemetry作業の自律書き込み先を限定するルールも追加した。

学習支援では、成長させすぎる失敗が出た

AI Learning Companionでは、学習量を増やした長期Simulationへ進んだ。0〜100のAbilityへ学習成果を直接足し続けると、275日相当のstress runで広い範囲が100近くまで飽和した。係数を遅くするだけでは、今度は短期の成長や正答率、継続率まで鈍る。そこで累積学習量のEXPと現在習熟度のAbilityを分け、長期の伸び方そのものを別の写像で扱う方向へ切り替えた。これは教育的な真値ではなく、Simulationが長期で破綻しないかを見るためのworking calibrationとして扱っている。

ヒントは、自由に書かせるほど安全になるわけではなかった

次に、Observableな学習状態だけから支援の深さを選ぶHint Intervention v1を作った。7種類のSynthetic profileを50 seedずつ、合計350 episodeで回し、不要な深掘りやpolicy違反が出ないことを確認した。ここまでは順調だった。

その次のNatural-language Hintでは失敗した。自由文を禁止語や数値、演算語で検査する初期Guardに、危険なHintを12件入れたところ8件がすり抜けた。禁止語を増やし続ける方式は採用せず、v1ではHint Planごとに承認済みの表現だけをtrusted outputとし、未知の言い換えはrejectする方式へ変更した。変更後はunsafe 12件を12件ともrejectできた。実LLMの自然文品質や教育的有効性は、まだ未検証のまま残している。

最後は、画面を作って実際に触り始めた

12日夜にはLearner Interfaceの実機試作へ進んだ。数式や数字をチップとして置き、動かし、途中式を組み立てる小さな操作盤を作った。スマートフォンで触ると、途中式を全部盤面へ保存し続けるには狭い。そこで思考キャンバスを『履歴を全部残す棚』ではなく、その場で使う作業台として扱い、最終回答は専用欄、途中過程は操作ログへ分ける方向へ変えた。設計図だけでは分からなかった摩擦が、触った瞬間に出てきた。

今回いちばん変わったところ

前回は『完成をどう決めるか』がテーマだった。その次に見えてきたのは、失敗しない仕組みを作るより、失敗を途中で止めて、原因を残し、戻れる仕組みを先に用意する方が現実的だということだった。Verification Harness、Build Watch Paths、append-only Telemetry、Human Gate、controlled Hint、research branchのstable化とarchive。別々の案件で作った仕組みだが、やっていることはかなり近い。AIに任せる範囲を広げるほど、止める場所と戻る場所を明示する必要がある。

この後

Learning Companionは、Learner Interfaceを実機で触りながら操作摩擦とObservableな学習行動を見ていく。AI Web Studioは、今回共通化した検証フォールバックやCloudflare初期設定が次の案件でも再発火するかを確認する。Anghel .labは、公開後の活動をRESEARCH NOTEとHUMAN RAMBLINGSへ分けて残す運用へ移る。次からは週次チェックで、記事にする価値のある差分だけを拾う。

完成候補が2つできた。さて、どう比べる？

Anghel .labのモーション案をChatGPTとClaudeで別々に作った。普通に考えると2つ並べて、良い方を選べば終わりに見える。でも評価するAIが作者名やbranch、実装説明を先に読んだら、画面を見る前から判断材料が混ざる。まず画面だけ、その後にコードを見る。この順番自体を決める必要があった。

今度は画面サイズを揃えられない

1920×1080と390×844で同じ条件を見たかったが、評価環境からそのサイズを正確に作れなかった。ここで『だいたい同じ』で進めると比較の意味が薄い。そこで固定サイズのiframeを使うEvaluation Harnessを作った。評価する仕組みまで作らないと、作品比較そのものが成立しないというのは想定外だった。

勝った方を丸ごと採用、にはしなかった

結果はClaude側を土台にすることにした。ただ、ChatGPT側にも残したい動きが4つあった。メニューの短いstagger、Research Noteの接続線、LABS操作時のpulse、WORKS番号の反応。コードごと持ち込むと負けた案の重さまで連れてくるので、意図だけ拾ってClaude側の作り方で入れ直した。AかBかを選ぶより、良かった部分を安全に残す方が大事だった。

そして『公開可能』判定で事故った

追加実装が終わったらもう一度確認すると決めていたのに、その実装前のcommitへ先に『正式公開可能』判定が出ていた。後からClaudeが時系列の食い違いを拾った。言われてみれば当たり前で、昔のcommitが合格していても、今から出すcommitが合格しているとは限らない。最後にrelease candidate commitとverified commitが同じかを見るルールを追加した。

人間が伝言係になる問題も出てきた

AIを分けるほど、人間が長い作業条件を別AIへコピーする回数が増える。これはかなり面倒だった。そこで作業内容、禁止事項、完了条件をGitHub Issueへ置き、AIにはIssue番号だけ渡せる形へ寄せた。ただしブラインド評価では、Issueを読むこと自体がネタバレになる。そこだけは専用の評価PackageやHarnessへ分ける。

今回いちばん変わったところ

AIで作る速度はもう十分速い。むしろ難しかったのは、『これで完成』をどう決めるかだった。作るAI、見るAI、直すAI、最後に確認するAIを分けても、その間の条件やcommitがずれていたら人間が全部つなぎ直すことになる。失敗が出たら個別に直すだけでなく、次から同じ事故を起こしにくいルールへ戻す。今はそちらの方が研究として面白くなっている。

この後

次は公開記事そのものを別AIに読ませる。記事も作って終わりではなく、書いた側と編集する側を分けて、本当に第三者が読める内容になっているかを見てから公開する。

作った本人に、そのまま採点させていいのか？

AIOSで役割を分けていく中で、1つ気になった。作ったAIがそのまま自分の案をレビューすると、見落とした前提まで一緒に持ち込むのではないか。そこでWeb Studioでは、作るAIと見るAIを分けて試すことにした。

Web Studioで試したこと

・ワイヤーフレーム工程を条件分岐で追加した ・GPTをMAIN_AI、Claude / GeminiをReviewerとして試した ・1つの案を複数AIが独立して見るRound方式を入れた ・Structure / Hierarchy / Interaction / Navigation / Responsiveなど観点を分けた ・3AIでRoundを進め、人間レビューへ渡すところまで試した

Learning Companionでも似た形が見えた

こちらはレビューではなく学習支援だが、単発で答えを返すだけでは足りない。本人がどこで詰まったか、ヒント後に進めたか、再挑戦したかを見て、その結果を次の支援へ戻す必要がある。正答率だけを見るより、途中の行動を観測した方が次に何をするか決めやすい。

違う案件なのに、同じ形になってきた

Web Studioでは『作る → 別AIが見る → 統合する → 人間へ戻す』。Learning Companionでは『観測する → 支援する → もう一度観測する → 次を変える』。やっていることは違うのに、AIの出力を一回で終わらせず、次の判断へ戻すLoopがどちらにも出てきた。

この後

Web Studioでは、複数AIレビューが本当に人間の確認負荷を減らすのかを実案件で試す。Learning Companionでは人工学習者を使い、観測ログだけから本人の特徴や弱点へどこまで近づけるかを見る。

完成したら終わり、でいいのか？

サイトが完成すると、その案件の修正点ばかり見ていた視点が少し離れる。そこで完成後にもう一度見直すCloseout工程を作ってみた。すると、案件そのものより制作基盤側の問題が目につくようになった。

AI Web Studioでやったこと

・Project Closeout工程を作った ・『案件完了』と『基盤改善完了』を分けた ・カフェ案件でCloseoutを試した ・CSS lintで大量の品質負債を検出して修正した ・共通Build検証に案件固有の前提が混ざっていることを見つけた ・別ジャンルの案件でも同じCloseoutを再実行した ・Production元とworkspace更新が結合している問題を見つけた

完成品をテストケースに戻す

制作中は『このページを直す』という目線になりやすい。完成後に見直すと、『なぜ毎回ここで確認が必要なのか』『別案件でも同じことが起きるのではないか』という見方ができる。作る → 観測する → 共通化する → 別案件で再確認する、という流れがここで見え始めた。

同じ頃、学習支援AIも始めた

AI Learning Companionでは、『宿題をAIに代行させない』ところから考え始めた。答えを出せることより、本人が身につけるべき部分をAIが奪わないことを先に決める。Web制作とは別のテーマだけれど、AIに何をさせるかより前に、させないことを決める点は共通していた。

この後

Web Studioでは、案件同士の公開影響をもっと分離する。Learning Companionでは、答えを禁止するだけでなく、本人の進み方に合わせて支援を変える方法まで考える。

サイトを作るところまでは速かった

AIに作ってもらうと、見た目を作るところはかなり速い。曖昧な修正でも会話しながら詰められるし、画像やCMSも後から差し替えやすい。ここだけ見れば『制作基盤、もうできたのでは？』と思えた。

実案件でやったこと

・AIを使った実案件ベースのWeb制作を始めた ・1つのworkspaceで複数案件を扱う構造へ移した ・共通基盤と案件固有ファイルを分離した ・Cloudflare PagesでPreview / Productionを試した ・公開画像を可逆WebPへ変換し、容量を約37%削減した ・Build成功時にも案件固有CSSが漏れる問題を見つけた ・作業branchから外部閲覧可能なPreviewが生成されるケースを確認した

面倒なのはその後だった

実際に複数案件を置くと、『今どの案件を触っているのか』『これはPreviewなのかProductionなのか』『この変更を公開していいのか』の方が危ない。Buildが成功していても表示は壊れるし、開発側では作業中のつもりでもHosting側では外から見えることがある。サイト生成だけ速くしても、その前後が曖昧なら人間が毎回確認することになる。

考え方を変えた

ここからAI Web Studioを『AIがサイトを作る場所』ではなく、制作・確認・案件分離・公開までをまとめて扱う基盤として考えるようになった。速く作れることは前提。その後に壊さず出せるかまで含めないと、実際には使いにくい。

この後

完成した案件をそのまま終わりにせず、もう一度テストケースとして使う。制作中には見えなかった品質負債や公開境界の問題を拾って、基盤側へ戻す。

最初に考えていたこと

AIに企画、実装、レビューと役割を増やしていけば、かなりのところまで任せられるのではないか。最初はそう考えていた。ところが役割を増やすほど、『誰が最後に決めるのか』『どの情報を正しいものとして扱うのか』が曖昧だと、AI同士のやり取りそのものが増えていった。

そこで先に決めたこと

・GitHubを正式情報の置き場所にする ・AIごとのRoleとHuman Fallbackを分ける ・Main PlannerとReviewerを分ける ・AI同士の議論は最大3Round。まとまらなければ人間へ戻す ・Task / Review / Decision / Handoverを別のものとして扱う ・複数AIの独立レビューを実際に試す

やってみて分かったこと

必要だったのは、AIを増やすことより先に判断経路を決めることだった。Reviewerも『正解を教えるAI』にすると役割が重なる。別の視点から穴を探す役にした方が分かりやすい。AIを便利な単体ツールとして足していくより、役割と戻り先を持つチームとして扱う方が整理しやすかった。

この後

紙の上で作ったルールだけでは意味がない。実際の制作案件へ持ち込んで、別AIや別セッションでも同じように動けるかを試す。