Foundation · 実行基盤（ハーネス）
対話で終わる AI と、 やり切る AI を分けるもの。
読む・調べる用途の対話型 AI と、 自ら手順を決めて作業を完了させる自律型エージェントの間には、 実装上の大きな隔たりがあります。 モデルや検索の延長では到達しません。 その差を埋める層が、 エージェントハーネス（実行基盤）です。 agens は、 その参照実装です。
- 停止条件（反復・時間・費用）12 / 40
- 進捗の永続化保存済
- 承認ゲート — 送信の直前で停止承認待ち
The gap
対話型 AI と自律型エージェントの、 技術的な隔たり。
同じ「AI を使う」でも、 実装の前提が違います。 差は能力ではなく、 実行を成立させる機構の有無に現れます。
| 観点 | 対話型 AIQA・要約・レビュー | 自律型エージェントハーネスが担う領域 |
|---|---|---|
| 求められること | 問いに答える | 作業を完了させる |
| 実行の単位 | 1 回の応答 | 数十回のツール呼び出し |
| 手順の決定 | 人が都度指示する | エージェントが自ら組み立てる |
| 出力の届く先 | 依頼した本人 | 他システム・他者 |
| 失敗の現れ方 | 回答の品質が低い | 途中で停止する／二重に実行される |
| 必要な実装 | モデル・検索・プロンプト | 左記に加え、 実行・統制・記録の機構 |
What must be added
隔たりの中身 — 追加で必要となる構成要素。
いずれも後から足せる部品ではなく、 実行の前提が変わるため基盤側の設計に含める対象です。
実行
対話型 AI では
モデル呼び出し 1 回で完結
自律型で新たに必要
- エージェントループ
- サンドボックス（コード実行）
- 長時間・非同期の実行
- 作業ファイル領域
接続
対話型 AI では
検索と参照
自律型で新たに必要
- ツール定義と MCP
- ツールの連鎖実行
- 段階的な読み込み
- ブラウザ操作
状態と回復
対話型 AI では
会話履歴の保持
自律型で新たに必要
- 実行状態の永続化
- 中断からの再開
- 失敗の分類と再試行
- 文脈の圧縮・退避
統制と運用
対話型 AI では
認証情報の管理
自律型で新たに必要
- 承認ゲート
- 実行の記録
- 権限の範囲
- 版管理と公開ゲート
Principles
実行基盤の、 原理原則。
実装の細部より先に決まる、 設計の前提です。 製品として組む場合も、 自社で内製する場合も共通します。
差がつくのは、反復そのものではない。
「計画 → 実行 → 観測」の反復そのものは単純です。 結果を左右するのは、 その反復を成立させている周囲の決定論的な仕組み——停止条件・再試行方針・承認・永続化——であり、 実装ごとに差が出るのもこの部分です。
要素が増えるのではなく、実行の前提が変わる。
対話型 AI は「答えを返して終わる」ことを前提に組まれます。 自律型では 途中で止まる・失敗する・再開する が常態です。 これらは後から足せる部品ではなく、 最初から基盤側の設計に含める対象になります。
短縮できるのは記述であって、検証ではない。
コード生成が速くなっても、 この層の難所は縮みません。 不具合の多くは構文や論理の誤りではなく、 モデルが想定と異なる振る舞いをしたときにのみ現れます。 同じ入力でも再現せず、 コードを変えなくてもモデル更新で挙動が変わる。 工数の大半は実装ではなく、 設計と検証に向かいます。
統制は「どの層で担保するか」の選択である。
望ましい進め方はプロンプトでも伝えられますが、 確率的にしか守られません。 金銭・不可逆・規制に関わる操作の唯一の防護をプロンプトにしない——実行時にコードで判定するゲートを置き、 結果は事後に記録で確かめる。 この 3 層の割り当てが設計の要点です。
接続は、API の接続ではなくプロトコルの設計。
対話 UI は 1 往復で完結する前提で作られています。 エージェントを載せると、 実行中の状態通知・停止・承認・再開といった双方向のやり取りが必要になります。 これは UI 側と実行層の双方に影響するため、 要件定義で先に決める対象になります。
Anti-patterns
ゼロから組むと、 ここで詰まる。
いずれも設計の誤りではなく、 実際に組み上げて動かした段階で表面化する挙動です。 塞がないまま進めると、 デモは通るが業務では使えない状態になります。
開発で表面化する
- 1
ループが終わらない
同じツールを呼び続ける、 または 1 回の失敗で作業を放棄する
停止条件と再試行方針が定義されていない
- 2
失敗が握り潰される
接続障害が「該当なし」という正常な結果として扱われる
障害と空の結果を区別していない
- 3
エラーが次につながらない
同一の呼び出しを、 条件を変えずに反復する
エラーが失敗の通知に留まり、 次の行動を示していない
- 4
ツールを選べない
接続先が増えるほど、 選択の精度が落ちる
全件を常時提示し、 段階的な読み込みがない
- 5
文脈が破綻する
長い作業の途中で上限に達し、 以降が成立しなくなる
圧縮・退避・再開の段取りが設計されていない
- 6
モデルを替えると動かない
別のモデルに切り替えると、 呼び出しが通らなくなる
プロバイダ間の差異を吸収する層がない
左から: 症状 ／ 現れ方 ／ 設計上の要因。
運用開始後に顕在化する
上の壁を塞いだ後も残る領域です。 断続的にしか発生せず、 検知されないまま推移します。 同一の入力でも結果が変動し、 失敗しているにもかかわらず正常な応答が返る—— 指標が存在しないため、 劣化そのものを検知できません。
途中で終了する
長時間の処理が完了せず、 進捗も記録されない
完了として扱われる
実は失敗しているが、 応答は正常な文面で返る
二重に実行される
再試行の際に、 送信や登録が重複する
前提が欠落する
作業の途中で、 金額・日付・ID の精度が失われる
中断により失われる
再起動や障害により、 進行中の作業が破棄される
劣化を検知できない
品質が低下しても、 比較対象となる指標が存在しない
Best practices
反復を成立させる、 決定論的な 6 つの仕組み。
モデルの出力によって迂回されない、 コード側の機構。 上のアンチパターンは、 いずれもこの 6 つのどれかの欠落として説明できます。
停止条件と予算
反復・実行時間・費用の上限を、 モデルの判断ではなくコード側で持つ。
agens: 反復回数・実行時間・費用の上限をタスク単位で設定し、 到達時は強制終了する。
失敗の分類と再試行
「障害」と「空の結果」を区別し、 再試行の可否と代替手段への切替を判定する。
agens: 失敗を種別で扱い、 再試行可否を判定。 二重実行を防いだうえで再開する。
承認ゲート
操作の種別で承認要否を判定し、 対象や引数が変われば再度確認する。 実行前に止める。
agens: 送信・更新・削除など、 影響の大きい操作は実行前に人の承認を挟める。
進捗の永続化
中断しても失わない。 途中から再開できる。 状態として保持する。
agens: 実行状態を保持し、 再起動・障害の後も途中地点から再開できる。
実行の記録
何を根拠に、 何を実行したか。 誰が承認したか。 事後の説明責任に必要になる。
agens: 監査ログは追記型で保持し、 承認者・対象・結果を後から一覧できる。
品質の計測
劣化の検知、 比較可能な指標、 再評価の基準。 単発の試験では再現しない領域を扱う。
agens: 手順・成果物の有無に対する自動検証に対応。 モデル更新時の再評価に使う。
Where to enforce
どの層で担保するか、 が設計の論点になる。
承認の保持と再開・実行記録の保全・権限の範囲・公開前の検証。 更新系の業務では、 これらが新たに要件になります。
層 1 — 方向づけ
プロンプトによる指示
望ましい進め方や判断の観点を伝えます。 確率的にしか守られないため、 金銭・不可逆・規制に関わる操作の唯一の防護とはしません。
層 2 — 実行前の制御
コードによるゲート
操作の種別により承認要否を判定し、 対象や引数が変われば再度確認します。 実行はランタイムが行うため、 モデルの出力によって迂回されません。
層 3 — 実行後の確認
検証と記録
意図した状態に到達したかを確認し、 実行内容と承認者を記録します。 事後の説明責任と、 品質劣化の検知の双方に必要です。
前提として、 継続運用が担保されて初めて機能します。 中断により作業が失われる状態では、 承認の記録自体が欠落し得ます。 権限・監査の詳細は コントロール をご覧ください。
Verification
品質検証の、 三層構造。
エージェントの挙動は、 モデル単体ではなく モデル・ハーネス・ツール・実行環境・ポリシーの組み合わせで決まります。 検証も、 その単位で設計する必要があります。
第 1 層 — 決定論的な検証
ツールとポリシーの単体テスト
入力に対する出力が一意に定まる部分を、 自動テストとして固定します。 回帰の検知が最も速く、 費用も低い層です。
継続的に自動実行
第 2 層 — タスク単位の検証
成果で採点するシナリオ実行
固定した業務シナリオを実環境で実行し、 最終的な環境の状態で合否を判定します。 応答文の妥当性ではなく、 結果で採点する層です。
中断・再開を含めて検証
第 3 層 — 長期挙動の検証
再開・文脈圧縮・承認分岐・引き継ぎ
長時間の実行で顕在化する挙動を検証します。 単発の試験では再現しにくく、 運用開始後に問題として現れやすい層です。
運用フェーズで継続
第 2 層の検証例: 処理の途中でサーバーを再起動し、 作業が中断地点から再開されることを確認する。 更新系では、 この種の検証を受入条件として設定します。
Reference implementation
ここまでの仕組みを、 製品として実装したもの。
agens は、 実行制御を中心に、 利用面・能力・記録までを一体で備えた実行基盤です。 セルフホストを前提に、 接続先と運用要件に応じて閉域構成も設計できます。
Adoption
採り方は、 3 通りあります。
製品として使う・自社環境に置く・自社の実行基盤として組む。 どれを選んでも、 前掲の設計論点は共通して現れます。
01 — そのまま使う
製品として導入する
実行制御・能力・記録が組み上がった状態から始めます。 ハーネスを自前で持たずに、 業務側の設計に集中できます。
agens を詳しく見る →02 — 自社環境で動かす
セルフホスト・閉域で置く
agens 本体・サンドボックス・データ・LLM 推論の置き場所を、 要件に応じて社内に寄せられます。 データを外部に出さない構成も組めます。
オンプレミス構成を見る →03 — 自社の基盤として組む
内製を、設計から一緒に
自社で実行基盤を持つ前提で、 要件定義・責任分界・受入条件から伴走します。 稼働している実装を参照点として、 設計の論点を先に潰します。
実行基盤の設計・構築支援を見る →Related
agens のほかの機能
これらはすべて、 ひとつの agens に含まれる機能です。 組み合わせて、 チャットから業務をまるごと任せられます。
FAQ
よくある質問。
エージェントハーネスとは何ですか?
対話型 AI をすでに導入しています。その延長で自律型にできますか?
自社環境（閉域）で動かせますか?
モデルは選べますか? 途中で替えられますか?
API ゲートウェイなどの統制基盤とは、どう役割が違いますか?
内製すべきか、製品を使うべきか、どう判断すればよいですか?
最終更新: 2026 年 8 月