Foundation · エージェンティック・ハーネス（AIエージェント実行基盤）
AIエージェントに業務の完了を任せる、エージェンティック・ハーネス。
調査、資料作成、システムへの登録など、複数の手順を含む業務を、必要なところで人の確認を挟みながら完了まで進めます。agensは、エージェントの実行・承認・中断からの再開・実行記録をまとめて扱う実行基盤です。フロントエンドを含めてセルフホストすることも、既存のアプリケーションから実行基盤だけを使うこともできます。
- 停止条件（反復・時間・費用）12 / 40
- 進捗の永続化保存済
- 承認ゲート — 送信の直前で停止承認待ち
What completion means
AIエージェントに、業務の完了を任せる。
回答を返すところまでではなく、成果物ができている・登録が済んでいる・対象システムが意図した状態になっている、というところまでを引き受けます。
調査と資料作成
複数の情報源を調べ、内容を整理して、指定された形式の資料を作成する。
完了の判定: 指定した形式のファイルが生成されている
社内申請・登録
必要な情報を集め、申請内容を作成し、人の承認を経てシステムへ登録する。
完了の判定: 対象システムに、承認を経た記録が作られている
データ分析
データを取得・加工・分析し、結果をファイルとして保存して関係者に共有する。
完了の判定: 成果物が保存され、共有まで終わっている
複数システムをまたぐ処理
社内データベースと外部サービスを照合し、条件に応じて更新処理を実行する。
完了の判定: 対象システムが、意図した状態になっている
「完了しました」という応答は、完了の証拠になりません。最終的なファイルが作成された、必要な登録が終わった、対象システムが意図した状態になった——完了は、この結果で確かめます。
How to use it
完成品としても、実行基盤だけでも使えます。
画面を含めて丸ごと導入するか、既存のアプリケーションを残したまま実行基盤だけを足すか。どちらでも、同じ実行・承認・再開・記録が働きます。
利用方法01
フロントエンドを含めて使う
agensを自社環境にセルフホストし、用意されたフロントエンドから利用します。実行状況・承認・成果物・履歴を扱う画面を、一から開発する必要がありません。
- 依頼と、実行状況の画面
- 承認の受付と、その履歴
- 成果物・作業ファイルの保管
- 利用者と権限の管理
利用方法02
既存システムから、実行基盤だけを使う
既存のチャット画面や業務アプリケーションを維持したまま、agensの実行・承認・再開・記録をAPI経由で呼び出せます。MCPサーバーとしても動くため、ツール実行とサンドボックスを外部のクライアントから使うこともできます。
- タスクの起動と、進捗の取得
- 承認要求の受け取りと、応答の返却
- 中断地点からの再開
- 実行ログの取得
- MCPでのツール・サンドボックスの公開
The run
依頼から完了まで、実際に何が起きるか。
止まらずに走り切ることではなく、止まっても失わずに完了へ戻ってくることを前提に組んでいます。
依頼
利用者が、完了させたい業務を依頼する。
計画
エージェントが、必要な手順を組み立てる。
実行
複数のツールとデータを横断して処理を進める。
承認
送信・更新・登録の前に、人の確認を求める。
中断
障害・再起動・予算の到達では、進捗を保存して止まる。
再開
中断した地点から、続きを実行する。
完了判定
成果物やシステムの状態で、完了を確認する。
記録
指示・ツール実行・承認者・結果を残す。
The gap
対話型AIの延長だけでは、業務を完了できない。
同じ「AIを使う」でも、実装の前提が違います。差は能力ではなく、業務を完了させる機構の有無に現れます。
| 観点 | 対話型AIQA・要約・レビュー | 自律型エージェントハーネスが担う領域 |
|---|---|---|
| 求められること | 問いに答える | 作業を完了させる |
| 実行の単位 | 1回の応答 | 数十回のツール呼び出し |
| 手順の決定 | 人が都度指示する | エージェントが自ら組み立てる |
| 出力の届く先 | 依頼した本人 | 他システム・他者 |
| 失敗の現れ方 | 回答の品質が低い | 途中で停止する／二重に実行される |
| 必要な実装 | モデル・検索・プロンプト | 左記に加え、実行・統制・記録の機構 |
What must be added
業務を完了するまでに、必要になる機能。
いずれも後から足せる部品ではなく、実行の前提が変わるため基盤側の設計に含める対象です。
実行
対話型AIでは
モデル呼び出し1回で完結
自律型で新たに必要
- エージェントループ
- サンドボックス（コード実行）
- 長時間・非同期の実行
- 作業ファイル領域
接続
対話型AIでは
検索と参照
自律型で新たに必要
- ツール定義とMCP
- ツールの連鎖実行
- 段階的な読み込み
- ブラウザ操作
状態と回復
対話型AIでは
会話履歴の保持
自律型で新たに必要
- 実行状態の永続化
- 中断からの再開
- 失敗の分類と再試行
- 文脈の圧縮・退避
統制と運用
対話型AIでは
認証情報の管理
自律型で新たに必要
- 承認ゲート
- 実行の記録
- 権限の範囲
- 版管理と公開ゲート
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層の検証例: 処理の途中でサーバーを再起動し、作業が中断地点から再開されることを確認する。更新系では、この種の検証を受入条件として設定します。
Principles
実行基盤の、設計原則。
実装の細部より先に決まる、設計の前提です。製品として使う場合も、自社で内製する場合も共通して現れます。
差がつくのは、反復そのものではない。
「計画 → 実行 → 観測」の反復そのものは単純です。結果を左右するのは、その反復を成立させている周囲の決定論的な仕組み——停止条件・再試行方針・承認・永続化——であり、実装ごとに差が出るのもこの部分です。
要素が増えるのではなく、実行の前提が変わる。
対話型AIは「答えを返して終わる」ことを前提に組まれます。自律型では途中で止まる・失敗する・再開するが常態です。これらは後から足せる部品ではなく、最初から基盤側の設計に含める対象になります。
短縮できるのは記述であって、検証ではない。
コード生成が速くなっても、この層の難所は縮みません。不具合の多くは構文や論理の誤りではなく、モデルが想定と異なる振る舞いをしたときにのみ現れます。同じ入力でも再現せず、コードを変えなくてもモデル更新で挙動が変わる。工数の大半は実装ではなく、設計と検証に向かいます。
統制は「どの層で担保するか」の選択である。
望ましい進め方はプロンプトでも伝えられますが、確率的にしか守られません。金銭・不可逆・規制に関わる操作の唯一の防護をプロンプトにしない——実行時にコードで判定するゲートを置き、結果は事後に記録で確かめる。この3層の割り当てが設計の要点です。
接続は、APIの接続ではなくプロトコルの設計。
対話UIは1往復で完結する前提で作られています。エージェントを載せると、実行中の状態通知・停止・承認・再開といった双方向のやり取りが必要になります。これはUI側と実行層の双方に影響するため、要件定義で先に決める対象になります。
The product
これらの機能を、agensで提供しています。
agensは、業務の完了に必要な実行・承認・再開・記録を、エージェンティック・ハーネスとして実装した製品です。セルフホストを前提に、接続先と運用要件に応じて閉域構成も設計できます。
Deployment
置き場所と、内製という選択肢。
利用方法を決めたあとに残る論点は、どこに置くか、そしてどこまでを自社で持つかです。
Related
agensのほかの機能
これらはすべて、ひとつのagensに含まれる機能です。組み合わせて、チャットから業務をまるごと任せられます。
FAQ
よくある質問。
エージェンティック・ハーネスとは何ですか?
業務が完了したことは、どう判定しますか?
既存のチャット画面や業務アプリを、置き換えずに使えますか?
対話型AIをすでに導入しています。その延長で、業務を完了させられますか?
自社環境（閉域）で動かせますか?
モデルは選べますか? 途中で替えられますか?
APIゲートウェイなどの統制基盤とは、どう役割が違いますか?
内製すべきか、製品を使うべきか、どう判断すればよいですか?
最終更新: 2026年9月