Act Operator – 「実運用向け」LangGraph 1.0+ プロジェクト制御ハーネスのオープンソース
(github.com/Proact0)同じAIモデルを使い、同じ人が扱っているのに、なぜ結果は違うのでしょうか。
毎回ベースを掘り起こして作り直し、チームごとに異なる方法でAgentを使うことでコード衝突が起き、運用できないプロトタイプばかりが積み上がる……
ここでは常に、AIツールを活用する人材同士の協業時に発生する慢性的な異常現象が起こります。
技術に慣れた開発者がClaude Codeにワークフロー実装を指示すると優れたコードが出てきます。ところが、初めて触れる開発者が同じClaude Codeに同じ依頼をすると、ありきたりで、一貫性がなく、微妙に間違ったコードが出てきます。同じモデルなのに、なぜでしょうか。
問題はモデルではなく、コンテキストギャップ(Context Gap) にありました — そしてこれは人間にもAIエージェントにも同じように当てはまります。
オンボーディングなしで投入された新しいチームメンバーが同じコードベースで迷ってしまう理由も同じです。コンベンションは暗黙的で、アーキテクチャは誰かの頭の中にしかなく、導いてくれる構造化された環境がありません。AIエージェントも同様です。
熟練者であってもこの壁にぶつかります。セッションが変わるとエージェントは過去の設計を忘れます。昨日決めたアーキテクチャを今日のエージェントは知りません。知識が人の頭の中にしかなく、コードベースの中にはないからです。人がコンベンションを見つけられなければ、エージェントも見つけられません。
これを解決するために必要なのは、プロンプト改善やより良いモデルではありません。人とエージェントが一緒に動く環境そのものを設計しなければなりません。
[ ハーネスはもともと存在していた。 ]
ハーネス(harness)という言葉は古フランス語の 'harnois' に由来します。もともとの意味は「軍事装備、制御のための道具」です。
1690年代から比喩的な意味が定着しました。「制御されていない力を正しい方向へ制御して利用する(to control for use as power)」という意味です。
風をエネルギーに変える風力発電所が「風をハーネシング(harnessing)する」と言うのと同じ文脈です。
工学では、この原則は形を変えながら繰り返し現れてきました。
- 電気配線ハーネス(Wiring Harness): 複雑に絡み合った配線をひとつの束にまとめ、制御可能な単位にする装置。自動車産業で何十年も標準です。
- テストハーネス(Test Harness): 全体インフラなしで特定コンポーネントを分離して実行できるようにする、スタブとドライバで構成された実行環境。ソフトウェアテストの中核概念です。
- CI/CDパイプライン: コードが直接本番環境に行かず、ビルド・テスト・検証レイヤーを通過するよう構造化された制御環境。これもひとつのハーネスです。
共通点はひとつです。
制御されていない対象(配線、コードコンポーネント、デプロイフロー)を正しい方向へ制御するための外部環境設計。
だからこそ、2026年初頭にOpenAIがCodexエージェントで5か月間、手動コード1行なしに100万行規模のシステムを構築した際、この古い原則をAIエージェントに適用したものをハーネスエンジニアリング(Harness Engineering)と名付けたのは自然な帰結でした。Martin Fowlerも、Anthropicのエンジニアリングチームも、同時期に同じ言葉を使ったのは偶然ではありません。
またLangChainもハーネスだけを改善して、Terminal Bench 2.0の順位を30位から5位へ引き上げました。
そのためact-operatorは、実際のプロダクトで使用できるLangGraph 1.0+構造制御用ハーネスとして作られました。
[ Ultra-Quick Start ]}
uvがインストールされた環境なら、以下の1行だけで実運用向けLangGraph 1.0+プロジェクトハーネスのセットアップが完了します。
uvx --from act-operator act new
[ Act Operatorの3層レイヤー ]
AIベース開発において、ハーネスとは、誰が作業しても関係なく、人間とAIエージェントの両方が正しい出力を安定して生成できるよう包み込む、スキャフォールディング、実行可能な知識、フィードバックループのシステムです。
Act Operatorはこれを3つのレイヤーで実装します。
- スキャフォールディング: 最初のエージェントプロンプトの前に組み立てられる、最小の疎結合と最小の高凝集が保証されたモジュール規約とベースクラスを内蔵した完全なプロジェクトスケルトン
- 実行可能なSSOT: エージェントと人間がランタイムに読む、動作可能なファイルにエンコードされた知識
- フィードバックループ: セッション間でエージェントをアラインした状態に保つ仕様
[ 実行可能なSSOT ]
一般的なチームは、開発・設計知識をWiki、アーキテクチャ文書、口伝知識で共有しますし、時にはそれすらしません。問題は、文書は古くなり、Wikiは陳腐化し、口伝知識はチームの変化を生き残れないことです。
ハーネスはこれらの知識を動くファイルとしてエンコードします — 静的な文書ではなく、エージェントと人間が直接読む実行可能なリファレンスです。Act Operatorは結合度と凝集度を考慮し、相互補完的な3つのSSOT構成要素レイヤーでこれを管理します。
- Act Template (scaffold): プロジェクトスケルトンそのもの — 基本CIワークフロー、ベースクラス、テスト構造、モノレポ設定、環境変数管理、利用ガイド
- Agent Skills: 合計5つのスキル、50以上の参照パターン、決定木、アーキテクチャテンプレート
- Drawkit: draw.io向けActアーキテクチャ事前定義シェイプ — 人同士のコミュニケーションのための共有視覚語彙
各構成要素は異なる対象を狙いながら、同じ基底コンベンションを参照します。Act Templateはエージェントと開発者の双方が作業する構造的基盤を確立します。スキルはその構造の中でエージェントが正しく構築する方法を、Drawkitはチームにアーキテクチャを可視化する方法を教えます。
[ オープンソースその他情報 ]
- Claude Code以外にも、OpenCode、Cursor、Gemini CLIなど、スキルディレクトリをサポートするツールならすべて動作します。
- 日本語/英語ドキュメントの両方をサポート
- Apache 2.0 License – PIPYで200%無料配布中
皆さまからのフィードバックとコントリビューションを歓迎します(そしてGitHubスター★も..!)。ありがとうございます :)
まだコメントはありません。