- ソフトウェア業界では最近、「ソフトウェアファクトリー（Software Factory）」という概念が大きな注目を集めています。与えられた目標に応じて複数段階の作業を自律的に実行するAIエージェントがソースコードの作成を専任し、開発者はそのコードを安定的に量産するシステム、つまり「工場」を構築・高度化することに集中するという新しいパラダイムです。
- AI開発ツール企業TesslのDru Knoxは、この新しい開発規律をハーネスエンジニアリング（Harness Engineering）と名付けました。
- ハーネス（Harness）とは、馬具のようにAIエージェントを制御し駆動するためのフレームワーク全体を意味し、このフレームワークの中核には3つのループ（Loop、同じ手順を繰り返し回る循環）が存在します。
- 動画で扱う内容: ソフトウェアファクトリーとは何か、それを規定する3つの指標 / Tesslが社内で対話型コーディングセッションを禁止した理由とその後 / Inner・Outer・Meta Loopという3つの層 / ハーネスエンジニアリングが難しい理由 / TesslのChange ReviewとVerifierがこれを実際に実装した方法
- 動画: https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236
同じ構造を知識生産に適用すると
- 知識ファクトリーは、AIエージェントがWikiページを作成し、人間はそれを量産する「編集局システム」を設計・運用する仕組みです。運用者は記事を直接書かず、執筆ガイドラインと自動化された検収メカニズムを管理します。
- 工場内部の組織は、新聞社の編集局における5つの役割体系をベンチマークしました。記者、コラムニスト、校閲、デスク、編集長です。
- ここで重要なのは、5つの役割すべてが「判断するAI」ではないという点です。「校閲」はAIではなくルールベースのPythonコードであり、「編集長」は作業を割り振る調整役です。AIが独立した評価判断を下す場は「デスク」1か所だけです。
- 効率的な工場設計とは、むやみにエージェント数を増やすことではなく、判断領域をどこに配置し、どこから排除するかを明確に定義することです。
成熟度の3軸、そして信頼
- システムの成熟度は、自律性（人間の介入なしにページを完成させること）、自動化（人間のレビューなしで公開を許可する範囲）、品質（生成された知識の水準）の3軸で測定します。
- 自律性が高くても、運用者が不安を感じてすべてのページを全数検査するなら、自動化の水準は低いままです。このギャップを埋める核心要素が「信頼」です。
- まず自律性を確保し、信頼が蓄積された範囲だけ自動化領域を拡張し、その過程で品質水準を一定に保ちます。そしてこの信頼を担保するメカニズムこそが「ループ」です。
1. Inner Loop — リアルタイムの自己点検
- Inner Loopは、エージェントがドラフトを提出する前、執筆プロセス中に随時実行する高速で軽量な検証手順です。このループが精緻であるほど、AIエージェントは人間の介入なしに自らエラーを修正し、結果として自律性が向上します。
- 執筆中はPython検査ツール（
tools/lint.py）で自分が作成した文書だけを検査し、同一エラーが2回以上繰り返された場合はただちに次の段階へ移管して処理速度を維持します。
2. Outer Loop — 公開直前の二重ゲート
- 第1ゲートは校閲です。Pythonコードがリンク、引用、文書構造、データの矛盾など10領域を、決定論的ルールに基づいて静的検査します。
- 第2ゲートはデスクです。偏り、情報密度、可読性、論旨の流れなど6つの観点から第三者読者の視点で定性的に評価し、直接修正はせず改善項目のリストだけを返します。
- これはソフトウェアファクトリーにおけるVerifier（第1ゲート）・Change Review（第2ゲート）の2段構造と同じです。
- ここには決定的な設計原則が1つあります。デスクには完成原稿と評価基準だけが渡され、書き手の執筆意図は渡されません。 同じ文脈の中で自分の文章を自分でレビューすると判定が甘くなるため、そもそも情報を遮断してそのバイアスを防ぐのです。
- このシステムの実質的な差別化要因は、エージェントをいくつ起動したかではなく、このようなコンテキストの隔離にあります。同一理由で3回拒否された場合は自動進行を停止し、人間の運用者に判断を委ねます。
3. Meta Loop — 自己改善メカニズム
- 「同じ失敗を二度繰り返させない。発見されたエラーはシステムのルールへ昇格させる」という原則に従います。
- 同一の欠陥が継続して発生すると、執筆ガイドラインの修正案を自動提案します。提案された修正案は、どちらが修正後のルールで書かれた文章なのかを隠して行うブラインド比較評価と、検証に一度も使っていない新しい失敗事例テストを経ます。
- 実際にスコアが向上した場合にのみ、そして必ず人間の運用者による最終承認を得た場合にのみ、システムに反映されます。
- 繰り返し指摘される事項はPythonフックや校閲ルールへ昇格させ、コードとして定着させます。定性的な判断領域をルール検査領域へ移管し、デスクが常に高次の問題に集中できるよう支援します。
4. Reground Loop — 知識にだけ必要な第4のループ
- ソフトウェアコードは一度ビルドされてデプロイされると、仕様変更までは安定状態を保ちますが、知識資産は時間の経過とともに現実の事実関係とのギャップが広がり、陳腐化します。
- これを解決するため、公開済み文書を再び知識生産工場の入力値としてフィードバックするReground（根拠に再び足場を置くという意味）Loopを第4のループとして追加しました。
- 更新: 元データソースに変更が発生した場合。検査ツールが特定した古くなったページをコラムニストが再分析して更新します。（続報）
- フォローアップ: 文書内に「後日確認が必要」または期限付き条件が明記された文が存在する場合。期限到来時にデスクおよび運用者が再検証します。（追跡取材）
- 訂正: 自分たちのページ間で情報の矛盾が検出された場合。デスクが公開済みクラスター単位の文書群をまとめて読み直し、1つずつ見ただけでは表面化しない食い違いを見つけます。（訂正報道）
Human-in-the-Loop
- 人間の承認が必要な例外状況を勘に頼らず、明確なチェックリストとして定義して管理します。
- 現在は自律性を高めつつ、自動化は意図的に抑えた状態で運用しています。エージェントはページを自律的に作成しますが、Wiki公開と執筆ルールの変更には、依然として人間による最終承認が必要です。
全文: https://alfadur7.github.io/llm-wiki-newsroom/ko/knowledge-factory/
まだコメントはありません。