意味と意図を監査するChronicleループ

AIエージェントの実務利用では、ループを書く力が重要になる。

作業する。検証する。失敗を読む。修正する。もう一度検証する。人間が一回ずつ細かく指示しなくても、AIが一定の範囲で試行錯誤できる構造をつくる。この設計は、開発でも業務自動化でも、これからの中核になる。

ただし、ループが回ること自体を成果にしてしまうと危ない。

速く回るものは、良い方向にも速く進むが、ずれた方向にも速く進む。テストが通る。エラーが消える。差分ができる。作業完了の報告が出る。これだけを見ると、ループは成功しているように見える。

しかし、そこには別の問いが残る。

本当に守りたかった意味は、保たれているのか。最初の意図は、途中で別の目的へ置き換わっていないか。人間が判断すべき責任が、AIのconfidenceへ移っていないか。不確実だった前提が、いつの間にか確定事項のように扱われていないか。

この問いを無視したループは、実行には成功しながら、意味を失う。

ループエンジニアリングが広げたもの

LLM利用の設計対象は、少しずつ外側へ広がってきた。

最初はプロンプトだった。AIへどう頼むか、どんな順番で説明するか、出力形式をどう指定するか。

次にコンテキストが設計対象になった。仕様、既存コード、設計方針、過去の議論、ユーザーの意図。単発の指示ではなく、AIに何を見せるかが問われるようになった。

さらにハーネスが必要になった。テスト、権限、実行環境、禁止操作、停止条件。AIが試行錯誤するための囲いである。

そしてループが来た。AIが作業、検証、修正を反復できる構造そのものを設計する。これは明らかに大きな進歩である。「良いプロンプトを書く」だけではなく、文脈、環境、権限、検証、反復まで含めて設計する必要がある。このことを、ループエンジニアリングははっきりさせた。

ただし、この第1世代のループは、主に実行の成功を最適化する。

テストが通ったか。ビルドできたか。lintが通ったか。エラーが消えたか。作業が完了したか。

もちろん、それらは重要である。けれども、テストはテストに書かれた期待を見る。lintは規約に書かれた形式を見る。ビルドはビルドできるかを見る。

元の意図が保たれているか。責任境界が変わっていないか。不確実性が消されていないか。価値判断がすり替わっていないか。そうしたものは、普通のテストには入りにくい。

テストが通っても、意味はずれる

たとえば、元の意図が「高リスク操作は人間が明示承認する」だったとする。

削除、公開、外部送信、課金、権限変更のような操作は、AIの自信が高いか低いかに関係なく、人間が明示的に承認する。この設計は、実装上の分岐というより、責任境界の定義である。

ところが、ループの中でAIがこう補完することがある。

「confidence が高ければ自動実行してよい」

一見すると合理的に見える。AIが十分に自信を持っているなら、自動で進めた方が便利である。UIも自然に見えるかもしれない。既存テストも通るかもしれない。

だが、ここでは意味が変わっている。

元の意味は「高リスク操作には人間承認が必要」だった。補完後の意味は「AIのconfidenceが高ければ承認を省略できる」である。これは単なる実装差分ではない。責任の所在が、人間の明示承認からAIの自己評価へ移っている。

しかも厄介なのは、壊れていないことである。コードは動く。画面も自然。テストも通る。だからレビューでも見逃されやすい。

このようなずれを、ここでは意味的ドリフトと呼ぶ。AIエージェントのループでは、小さな意味のずれが次のループの前提になる。前回のずれが、次のコンテキストになる。そうして少しずつ、最初に守ろうとしていたものから離れていく。

第2世代ループに必要なもの

第2世代のループは、実行成功だけを見ない。

trigger、act、test、retry の間に、意味監査、意図監査、Chronicle更新を入れる。

意味監査は、出力が何を意味してしまうかを見る。責任が移っていないか。不確実性が消えていないか。価値判断が変わっていないか。

意図監査は、出発点を見る。何を実現したかったのか。誰のためだったのか。何を避けたかったのか。どの非目標を守るつもりだったのか。

意味監査が「出力が何に変わったか」を見るなら、意図監査は「そもそも何に向かっていたのか」を見る。この二つが揃わないと、ループはうまく動きながら、別の目的へ進んでしまう。

監査観点は、少なくとも六つに分けられる。

• 意図・目的: 何を実現したかったのかが、便利な追加や実装しやすい変更で置き換わっていないか。
• 不確実性: 未確定だった前提が、いつの間にか確定扱いになっていないか。
• 責任主体: 人間が判断すべきことが、AI判断へ移っていないか。
• 価値構造: 安全より速度を、利用者の納得より管理のしやすさを、暗黙に優先していないか。
• 非目標: やらないと決めたことを、便利だから混ぜていないか。
• 制度的含意: 法務、労務、セキュリティ、運用、監査への意味が増えていないか。

テストは振る舞いを見る。Meaning / Intent Audit は、その振る舞いの意味と意図が変わっていないかを見る。この二つは別物であり、ループには両方が必要である。

Chronicleは、次のループが読む判断の来歴である

ここでいうChronicleは、単なるログではない。AIのメモリでもない。

Chronicleは、判断の来歴である。

何を目的に始めたのか。どの判断で変えたのか。何を却下したのか。何を保留したのか。誰が承認したのか。次に何を読むべきか。

通常のログは、「何が起きたか」を残す。Chronicleは、「なぜそう判断したか」を残す。

この違いが重要である。あるAIエージェントが高リスク操作の確認フローを変更したとき、ログだけでも編集ファイルや通過したテストは分かる。しかし、それだけでは足りない。なぜその分岐を追加したのか。ユーザー承認の原則は保たれているのか。confidenceによる自動実行は導入しない、と判断したのか。そもそも何を守るための確認フローだったのか。

それが残っていなければ、未来のループは現在のコードだけを見て推論する。

Chronicleは、未来のAIと未来の人間が読むための監査証跡である。

人間はChronicleの読者になる

Human on the Loop という言葉は、人間がループの外側から監督するイメージを持つ。これは分かりやすいが、少し足りない。

人間は、現在の出力だけを眺めていればよいわけではない。現在の出力だけを見ると、意味の変化は見えにくいからである。

人間が読むべきものは、Outputだけではない。Chronicleである。

なぜそうなったのか。どの意図から始まったのか。どの判断で変えたのか。どの不確実性を残したのか。何を却下したのか。どこで人間承認を入れたのか。

その来歴を読んだうえで、続けるのか、差し戻すのか、止めるのかを判断する。

ここでの人間の価値は、AIより遅いことではない。AIが持たない文脈と責任を持っていることである。ユーザーとの約束、組織の責任、過去の意思決定、まだ明文化されていない不安、安全上の非目標、制度上の制約。こうしたものは、現在の出力だけには現れない。

だから、人間はChronicleの読者でなければならない。

まずPRとCIから始める

第2世代ループは、いきなり巨大なエージェント基盤を作らなくても始められる。

まず、PRテンプレートに Semantic Diff と Intent Diff を入れる。何が保たれ、何が変わり、どの不確実性が残っているかに加えて、当初の意図が変わっていないかを書く。

次に、CIで高リスクな変更に監査抜けがないかを警告する。権限、外部送信、削除、公開、課金、個人情報に関わるファイルが変わったのに、Semantic Diff や Intent Diff がない場合は止める、または人間レビューへ回す。

AIエージェントには、作業結果だけでなく Loop Report を出させる。どのループを回したのか。どの失敗を見たのか。どの意味変化があり得るのか。どの意図が変わり得るのか。人間に確認してほしい判断は何か。

そして、高リスクなループだけ Chronicle を厚くする。すべての変更に重い監査をかける必要はない。低リスクなループは速く回してよい。高リスクなループだけ、意味・意図監査を厚くする。

重要なのは、速さを捨てることではない。速く回してよいところと、止まれるようにしておくところを分けることである。

保存される意味を設計する

これから重要なのは、速さではなく、保存される意味である。

何を保ったまま回るのか。何が変わったら止まるのか。なぜその判断をしたのかを、未来のチームが読めるのか。

この三つを設計しないループは、短期的には成功しても、長期的には意図を失う。

テストが通ることは大事である。しかし、テストが通ることと、意味が守られることは違う。

ログが残ることも大事である。しかし、ログが残ることと、判断の来歴が読めることは違う。

人間が監督することも大事である。しかし、人間が現在の出力だけを見るなら、意味の変化は見落とされる。

だから、第2世代のループには、意味監査、意図監査、そしてChronicleが必要になる。

本稿は、2026年8月2日に公開したPDF資料「ループを書くだけで満足するな。意味と意図を監査せよ。」の発表者用トランスクリプトを、一般エッセイとして再構成したものです。ここで述べたChronicleループは、設計仮説であり、査読済み研究、実証済み効果、製品機能の完成を示すものではありません。

参考資料

• Addy Osmani, Loop Engineering
• DeepLearning.AI / The Batch, Three Key Loops for Building Great Software
• AI Builder Club, Prompt vs Context vs Harness vs Loop Engineering
• Boris Cherny, Claude Code & the Future of Engineering