Agentic Harness Engineering
AIエージェントの実行基盤を、
自社で持つために。
読む・調べる用途の対話型AIと、自ら手順を決めて作業を完了させる自律型エージェントの間には、実装上の大きな隔たりがあります。homulaは、その差を埋める実行層——エージェンティック・ハーネス——の要件定義から設計・構築・運用までをご支援します。
内製および自社環境でのホスティングを前提とした支援です。特定の製品・クラウド・フレームワークへの依存を前提としません。当社が開発・運用する実装（agens）は、設計の参照点としてご提示します。
4要素
自律型で新たに必要になるもの
6機構
反復を成立させる決定論的な仕組み
3層
統制を担保する層／検証の設計単位
閉域対応
オンプレミス・自社ホスティング前提
The Gap
対話型AIと自律型エージェントの、
技術的な隔たり
モデルや検索の延長では到達しません。差は能力ではなく、実行を成立させる機構の有無に現れます。
| 観点 | 対話型AIQA・要約・レビュー | 自律型エージェントハーネスが担う領域 |
|---|---|---|
| 求められること | 問いに答える | 作業を完了させる |
| 実行の単位 | 1回の応答 | 数十回のツール呼び出し |
| 手順の決定 | 人が都度指示する | エージェントが自ら組み立てる |
| 出力の届く先 | 依頼した本人 | 他システム・他者 |
| 失敗の現れ方 | 回答の品質が低い | 途中で停止する／二重に実行される |
| 必要な実装 | モデル・検索・プロンプト | 左記に加え、実行・統制・記録の機構 |
この差を埋める層が、ハーネスです。
手順が事前に決まらない以上、いつ止めるか・失敗をどう扱うか・完了をどう判定するかを、すべて実装側で定める必要があります。初期開発の段階から、対話型AIとは別種の設計を要します。
What Must Be Added
隔たりの中身 — 追加で必要となる構成要素
いずれも後から足せる部品ではなく、実行の前提が変わるため基盤側の設計に含める対象です。
実行
対話型AIでは
モデル呼び出し1回で完結
自律型で新たに必要
- エージェントループ
- サンドボックス（コード実行）
- 長時間・非同期の実行
- 作業ファイル領域
接続
対話型AIでは
検索と参照
自律型で新たに必要
- ツール定義とMCP
- ツールの連鎖実行
- 段階的な読み込み
- ブラウザ操作
状態と回復
対話型AIでは
会話履歴の保持
自律型で新たに必要
- 実行状態の永続化
- 中断からの再開
- 失敗の分類と再試行
- 文脈の圧縮・退避
統制と運用
対話型AIでは
認証情報の管理
自律型で新たに必要
- 承認ゲート
- 実行の記録
- 権限の範囲
- 版管理と公開ゲート
Principles
実行基盤の、原理原則
実装の細部より先に決まる、設計の前提です。内製・製品導入のいずれを選んでも共通して現れます。
差がつくのは、反復そのものではない
「計画→実行→観測」の反復そのものは単純です。結果を左右するのは、その反復を成立させている周囲の決定論的な仕組み——停止条件・再試行方針・承認・永続化——であり、実装ごとに差が生じるのもこの部分です。
要素が増えるのではなく、実行の前提が変わる
対話型AIは「答えを返して終わる」ことを前提に組まれます。自律型では、途中で止まる・失敗する・再開することが常態です。これらは後から足せる部品ではなく、最初から基盤側の設計に含める対象になります。
短縮できるのは記述であって、検証ではない
コード生成が速くなっても、この層の難所は縮みません。不具合の多くは構文や論理の誤りではなく、モデルが想定と異なる振る舞いをしたときにのみ現れます。同じ入力でも再現せず、コードを変えなくてもモデル更新で挙動が変わる。工数の大半は実装ではなく、設計と検証に向かいます。
統制は「どの層で担保するか」の選択である
望ましい進め方はプロンプトでも伝えられますが、確率的にしか守られません。金銭・不可逆・規制に関わる操作の唯一の防護をプロンプトにしない——実行時にコードで判定するゲートを置き、結果は事後に記録で確かめる。この3層の割り当てが設計の要点です。
接続は、APIの接続ではなくプロトコルの設計
対話UIは1往復で完結する前提で作られています。エージェントを接続すると、実行中の状態通知・停止・承認・再開といった双方向のやり取りが必要になります。UI側と実行層の双方に影響するため、要件定義で先に定める対象になります。
Anti-patterns / Build
ゼロから組む場合に、直面する壁
いずれも設計の誤りではなく、実際に組み上げて動かした段階で表面化する挙動です。塞がないまま進めると、デモは通るが業務では使えない状態になります。
ループが終わらない
同じツールを呼び続ける、または1回の失敗で作業を放棄する
停止条件と再試行方針が定義されていない
失敗が握り潰される
接続障害が「該当なし」という正常な結果として扱われる
障害と空の結果を区別していない
エラーが次につながらない
同一の呼び出しを、条件を変えずに反復する
エラーが失敗の通知に留まり、次の行動を示していない
ツールを選べない
接続先が増えるほど、選択の精度が落ちる
全件を常時提示し、段階的な読み込みがない
文脈が破綻する
長い作業の途中で上限に達し、以降が成立しなくなる
圧縮・退避・再開の段取りが設計されていない
モデルを替えると動かない
別のモデルに切り替えると、呼び出しが通らなくなる
プロバイダ間の差異を吸収する層がない
左から: 壁 ／ 現れ方 ／ 設計上の要因
短縮できるのは記述であって、検証ではありません。
実装の速度が上がっても、この層の難所は縮みません。ハーネスの正しさは記述量ではなく、モデルの挙動を前提に置いた設計で決まるためです。工数の大半は、実装ではなく設計と検証に向かいます。
Anti-patterns / Production
継続運用で顕在化する、設計課題
前掲の壁を塞いだ後も残る領域です。断続的にしか発生せず、検知されないまま推移します。同一の入力でも結果が変動し、失敗しているにもかかわらず正常な応答が返る。指標が存在しないため、劣化そのものを検知できません。
途中で終了する
長時間の処理が完了せず、進捗も記録されない
完了として扱われる
実は失敗しているが、応答は正常な文面で返る
二重に実行される
再試行の際に、送信や登録が重複する
前提が欠落する
作業の途中で、金額・日付・IDの精度が失われる
中断により失われる
再起動や障害により、進行中の作業が破棄される
劣化を検知できない
品質が低下しても、比較対象となる指標が存在しない
これらはいずれも、停止条件・分類と再試行・進捗の永続化・完了判定・品質の計測の欠落に対応します。機能追加では解消せず、実行基盤側の設計事項となります。
Best Practices
反復を成立させる、決定論的な6つの仕組み
モデルの出力によって迂回されない、コード側の機構です。前掲のアンチパターンは、いずれもこの6つのどれかの欠落として説明できます。
停止条件と予算
反復・実行時間・費用の上限を、モデルの判断ではなくコード側で持つ。到達時は強制終了する。
失敗の分類と再試行
「障害」と「空の結果」を区別し、再試行の可否と代替手段への切替を判定する。二重実行を防いだうえで再開する。
承認ゲート
操作の種別により承認要否を判定し、対象や引数が変われば再度確認する。実行の前に止める。
進捗の永続化
中断しても失わない。途中から再開できる。実行状態として保持する。
実行の記録
何を根拠に、何を実行したか。誰が承認したか。事後の説明責任と、原因の切り分けに必要になる。
品質の計測
劣化の検知、比較可能な指標、再評価の基準。単発の試験では再現しない領域を扱う。
Where To Enforce
どの層で担保するか、が設計の論点になる
承認の保持と再開・実行記録の保全・権限の範囲・公開前の検証。更新系の業務では、これらが新たに要件となります。
層1 — 方向づけ
プロンプトによる指示
望ましい進め方や判断の観点を伝えます。確率的にしか守られないため、金銭・不可逆・規制に関わる操作の唯一の防護とはしません。
層2 — 実行前の制御
コードによるゲート
操作の種別により承認要否を判定し、対象や引数が変われば再度確認します。実行はランタイムが行うため、モデルの出力によって迂回されません。
層3 — 実行後の確認
検証と記録
意図した状態に到達したかを確認し、実行内容と承認者を記録します。事後の説明責任と、品質劣化の検知の双方に必要です。
※ 前提として、継続運用が担保されて初めて機能します。中断により作業が失われる状態では、承認の記録自体が欠落し得ます。
Verification
品質検証の、三層構造
エージェントの挙動は、モデル単体ではなく モデル・ハーネス・ツール・実行環境・ポリシーの組み合わせで決まります。検証も、その単位で設計する必要があります。
第1層 — 決定論的な検証
ツールとポリシーの単体テスト
入力に対する出力が一意に定まる部分を、自動テストとして固定します。回帰の検知が最も速く、費用も低い層です。
継続的に自動実行
第2層 — タスク単位の検証
成果で採点するシナリオ実行
固定した業務シナリオを実環境で実行し、最終的な環境の状態で合否を判定します。応答文の妥当性ではなく、結果で採点する層です。
中断・再開を含めて検証
第3層 — 長期挙動の検証
再開・文脈圧縮・承認分岐・引き継ぎ
長時間の実行で顕在化する挙動を検証します。単発の試験では再現しにくく、運用開始後に問題として現れやすい層です。
運用フェーズで継続
第2層の検証例: 処理の途中でサーバーを再起動し、作業が中断地点から再開されることを確認する。更新系では、この種の検証を受入条件として設定します。
Engagement
ご支援の形態
御社での構築を前提に、要件定義期からご一緒できる形態を整理しました。まずは要件定義の共同整理からの着手をおすすめします。
要件定義の共同整理
実行基盤に求める要件を、合否基準・優先度・担当区分（内製／ベンダー／統制基盤側）まで整理します。統制基盤との責任分界点、および受入条件も同時に定めます。
実行基盤の共同開発
承認・記録・完了判定・耐久実行など、標準機能として提供されにくい領域を、御社の要件と共同で設計・実装します。
参照実装の活用
稼働済みの実装（agens）を出発点とする形態です。内製の定義と調達方式をご確認のうえ、権利・利用条件を個別にご相談します。
外部レビュー
設計・実装の第三者評価。当社が設計に関与する場合は、担当の分離、または他社によるレビューをご検討ください。
※ 各形態の実施範囲・期間・費用、および成果物の権利・利用条件は、協議のうえ確定します。開発・テスト期には、閉域に設置した確認環境をご提供し、要件の妥当性を実機でご確認いただくことも可能です。
Deliverables
ご提供する成果物
御社での継続運用を想定し、必要な成果物と引継ぎ方法を支援形態に応じて設計します。
01 — 要件定義
要件定義票
- 各項目の合否基準と優先度
- 担保する層の割り当て
- 担当区分（内製／ベンダー／統制基盤側）
- 対象外とする項目と、その理由
02 — 設計
責任分界表と設計方針書
- 統制基盤とハーネスの分界点
- 承認・記録・権限の設計方針
- 接続方式の検証項目
- 想定される論点と選択肢
03 — 検証
受入条件と検証シナリオ
- 更新系業務の受入条件
- 検証シナリオの雛形
- 運用開始後の確認項目
- 再評価のタイミング
How We Start
対象領域を限定した、初期作業から
全体を一度に実施する必要はありません。優先される1領域を選定いただき、要件定義票の形式で成果物をご提示します。内容をご確認のうえ、以降の進め方をご判断ください。
01
対象領域の選定
実行基盤の設計論点のうち、御社で優先される1領域を選定します。全体を一度に実施する必要はありません。
02
現況の確認
既存アプリケーションの運用実態と、自律化にあたってのご想定を確認します。
03
要件定義票の作成
合否基準・優先度・担保する層・担当区分を整理し、成果物としてご提示します。
04
ご確認とご判断
成果物をご確認のうえ、以降の座組（内製の範囲・共同開発・参照実装の活用）を協議します。
Why homula
設計の知見は、自社実装の運用から出ています
参照実装を、自ら開発・運用している
当社は、AIエージェント実行基盤 agens を開発・運用しています。前掲のアンチパターンと対処は、この層の実装を通じて把握したものです。机上の整理ではありません。
閉域・オンプレミス構成の実装経験
実行基盤本体・サンドボックス・データ・LLM推論のそれぞれについて、置き場所を設計した経験があります。規制業界の要件に沿った構成の検討にも対応します。
製品導入を前提としない支援
本サービスは設計・実装の支援です。当社製品の採用を前提とせず、モデル・クラウド・フレームワークの選定は御社の制約と要件に沿って整理します。
FAQ
よくあるご質問
AIモデルに、仕事をやり切らせるための周辺機構をまとめて与える実行層です。エージェントループ・ツール接続・実行環境（サンドボックス）・メモリ／文脈管理・停止条件・承認ゲート・実行の記録などが含まれます。モデルや検索の延長では到達せず、実装側で定める対象になります。「AIエージェント実行基盤」とほぼ同義で用いられます。
判断の分かれ目は、実行基盤そのものを自社のコア能力として持つかどうかです。持つ場合でも、停止条件・再試行・承認・永続化・記録といった標準機能の設計は共通して必要になります。本サービスは内製を前提とした支援ですが、要件定義の段階で「どこまでを自社で持ち、どこから調達するか」を含めて整理します。製品側の構成は、参照実装のページをご覧ください。
はい。むしろ、その前提でのご相談が中心です。実行基盤本体・サンドボックス・データおよび成果物・LLM推論のそれぞれについて、置き場所を要件に応じて設計します。外部通信の要否は、採用する機能と接続方式を踏まえて確定します。
重複しません。統制基盤は「誰がどのAPIに到達してよいか」を、ハーネスは「そのAPIを呼ぶ前に人が確認するか」を扱います。境界側の記録に残るのは主に「どのAPIが呼ばれたか」であり、判断の経緯と承認の記録をどちらの層で保持するかが設計上の論点になります。この分界点の整理は、要件定義の初期に扱う項目です。
接続のみで成立する範囲は限られます。対話UIは1往復で完結する前提で作られているため、実行中の進捗提示・中断と方向修正・承認の提示と応答・成果物の受け渡しといった面が新たに必要になります。既存資産を活かせる範囲は広いものの、実際の差分は現行仕様をご確認のうえ確定します。
はい。本サービスは設計・実装の支援であり、当社製品の導入を前提としません。モデル・クラウド・エージェントフレームワークの選定は、御社の制約と要件に沿って整理します。当社の実装（agens）は、設計の参照点および比較対象としてご提示します。
対象領域と支援形態によって異なります。まずは優先される1領域に絞って要件定義票を作成し、内容をご確認のうえ以降の進め方をご判断いただく形をおすすめしています。実施期間・成果物の範囲・費用は、対象領域の確定後に協議のうえ決定します。
Get Started
実装の前に、
設計の論点を潰しておく
まずは30分のオンライン相談で、現在のご構想と制約を伺います。優先される1領域に絞った要件定義からの着手も可能です。
30分のオンライン相談 → 対象領域のご提案を3営業日以内にお送りします