AIエージェントへのハーネスエンジニアングのために社内規定 as a Codeにプルリクを出せる組織が真のアジリティを獲得する

HITLが組織のボトルネックとなる

業務をAIエージェントで効率化しようという話になると、とにかく「事故らないように人間が確認できる仕組みが大事ですね」という話ばかりが出てきがちだ。部下の仕事はそんなに見てなかったはずなのに。仮にAI化を進めたところで、すべてのアウトプットを人間がレビューしていくのであればむしろ時間がかかり、組織のアジリティ（俊敏性）が失われてしまうし、結局はめくら印が横行することだろう。かといって完全にAIに任せるのも難しい。

ではLLMの側にガードレールを仕込めばいいかというと、物理的に実行不可能にしなければ安全性は確保できない。Claude Codeのようなコーディングエージェントが.envを読んでAPIキーを直接使えてしまう状態では、どんなに巧妙なプロンプトでガードレールを仕込んでも突破される可能性がある。LLMの出力を制御・検証する仕組みを構築する技術を"ハーネスエンジニアリング"と呼ぶが、これを真面目にやろうとすると、エージェントに渡す「リスク許容バジェット」を設計し、仮に.envが漏洩しても最大利用金額と可能アクションがAPI側で制限されていれば致命傷にはならないという仕組みの話になっていく。

「おまかせ」は全権委任であり、主導権はAIに移る。「おせっかい」は主導権を人間に残したまま、気づきと提案を差し挟む。

以前おせっかいなAmbient Agentについて書いたことがあるのだけど、エージェントのガバナンスにも同じ構図がある。欲しいのは「おまかせ」でも「放置」でもなく、境界線の内側では自由に動かしつつ逸脱時だけ介入する「おせっかい」型の権限委譲だ。

この境界線の理念を実現しようとして、if (budget > X && time == Y && user_role == Z && vendor_approved == true)というIF文を増やしていっても、破綻するのが目に見えているため、ポリシーを宣言的に定義していく必要が出てくるのだけど、これは結局のところ社内規定集 as a Codeになるのだと気づいた。

OPAが「決定」と「執行」を引き離す

ChatGPTの佐藤美咲問題にあえてブレるStochastic RAGで意図的な突然変異を誘発する

すべての道は佐藤美咲に通ず

ChatGPTに「この商品のターゲットとなる仮想ペルソナを提案して」と頼むと、驚くほどの確率で「佐藤美咲」という名前が返ってくる。28歳、都内在住、IT企業勤務。プロンプトを変えても佐藤美咲は何度でも蘇る。ちょっとした恐怖小説なような気もするけれども、佐藤は日本最多の姓であり、美咲は平成時代に通算8回もの命名ランキング1位を獲得した名。つまり、統計的な最頻値としての「正解」が reasoning_effort に応じて選択されているとオチだ。

この現象は名前の問題にとどまらない。カスタマーデジタルツインのペルソナ設計をChatGPTに依頼したとき、3回連続で28歳、都内在住、IT企業勤務の概念佐藤美咲が出てきたことがある。プロンプトを変えても、コンテキストを変えても、佐藤美咲っぽい類型は不死鳥のように蘇る。

名言の選出も同じだ。Cronで起動するエージェントに「コアコンセプトとなるビジネス名言をランダムに選出して、それを元に施策を提案して」と指示しても、出てくるのは同じような話ばかり。LLMの「ランダム」は人間が期待するランダムとはまったく異質のものだ。確率分布の最頻値を中心にした狭い範囲でしか揺らがないそれは、統計的に正しいが創造的には貧困である。

LLMの最頻値収束とレコメンドエンジンの罠

同じ親から生まれたスクラムとSECIモデルはAIエージェントによる暗黙知のリバースドキュメンテーションで再合流する

「問題無ければ次へ」に眠る暗黙知

手順書に「問題無ければ次へ」と書いてあったり、ログ収集手順は書いてあるがログをどう見るかまでは書いてなかったりしませんか？
その「問題無ければ」や「ログの見方」がナレッジです。問題有無判断方法やログ確認手法まで書いてあれば、たとえ実体が手順書でもそれは形式知化されたナレッジです https://t.co/JsKEerIwA9

— タマゴケ (@s5ml) 2026年2月11日

Xで見かけたこの投稿をきっかけに、ずっと考えていたことが一本の線につながった。運用手順書に「問題無ければ次へ」と書かれている場面を何度も見てきた。一見すると親切な手順書なのだけど、この一行が隠蔽しているものは途方もなく大きい。「問題無ければ」の判断基準はどこにも書かれていない。ベテランのエンジニアは ps コマンドを打ち、ログの特定の行を目視し、レスポンスタイムの微妙な変化を体感的に察知して「問題無し」と判断する。その判断プロセスこそが暗黙知であり、手順書のどこにも記述されていない。

「じゃあ暗黙知を書き出せばいいじゃないか」という話になるのだけど、書き出せないから暗黙知なのだ。レシピ本に書かれた「塩少々」を読んで料理が上手くなるわけではない。知識には意図・目的・文脈が必要であり、「なぜ ps を打ったのか」「ログのどこを見ているのか」「何と比較して正常と判断したのか」という Why の連鎖がなければ、手順書はただの呪文になる。

野中郁次郎と竹内弘高が定式化した SECIモデルは、この暗黙知の問題に正面から取り組んだフレームワークだ。共同化（Socialization）で経験を共有し、表出化（Externalization）で言語化し、連結化（Combination）で体系化し、内面化（Internalization）で再び身体知に落とし込む。ペアワークで隣に座って「なぜ今 ps 打った？」と問い、ポストモーテムで「ログのどこを見て判断した？」と掘り下げる。この地道なサイクルこそが、「問題無ければ次へ」の行間を埋める唯一の方法だった。

何を載せるか＝何を載せないかを問う方法論。コンテキストエンジニアリングも本質は同じだ。LLMに何を渡し、何を渡さないか。CLAUDE.mdやSKILL.mdは「編集指針」の明文化であり、AIエージェントが参照する暗黙知のリバースドキュメンテーションにほかならない。

リバースドキュメンテーション、つまり先に動き、後から書く。この概念が SECIモデルのサイクルそのものと合流しつつあることが気づかれて始めている。そしてその合流は偶然ではない。

スクラムとSECIモデルは同じ親ブランチから生まれた