Harnessとは？ AIを業務アプリに組み込むための設計入門
T. N.AIを業務アプリに組み込むときは、指示文だけでなく、AIへ渡す情報や生成結果を使う条件も決める必要があります。本記事では、その前後の処理を支えるHarnessを日報アプリの例で解説し、AIに任せる部分とアプリが管理する部分を整理します。
1. Harnessとは：AIの前後に、アプリが担う仕事がある
Promptは、AIに任せる仕事、返答の形式、判断基準を伝える指示です。Harness（ハーネス）は、必要な情報の準備、モデルの呼び出し、結果の確認、保存条件をアプリ側で支える仕組みです。
次の表は、AIへの指示とアプリ側で担う処理の違いを日報の例で示します。
| Promptに書くこと | Harnessとしてアプリに実装すること |
|---|---|
| AIに任せる仕事、返答の形式、判断基準 | 必要な記録の取得、AIの呼び出し、結果の検査、保存条件 |
| 例：「今日の記録から日報案を作る。記録にない成果は補わない」 | 目的に合う記録を選び、閲覧権限を確認する。出力を検査し、本人確認後に保存する |
| 処理 | 誰が何をするか | アプリが決めること |
|---|---|---|
| 目的を受け取る | 本人が今日の日報や振り返りなどを選ぶ | 誰の、何のための処理か |
| 材料をそろえる | アプリが目的に応じて記録を選び、閲覧権限を確かめる | 対象・期間・粒度とAIへ渡す情報の範囲 |
| 下書きを作る | モデルが材料から日報を書く | 何をまとめ、何を推測で補わないか |
| 下書きを確認する | アプリが日付や参照先を検査し、本人が内容を確認する | 自動検査と本人確認の範囲 |
| 確定して保存する | アプリが本人の確認した内容を保存する | 保存条件と、入力が変わった場合の扱い |
図は、Harnessが支える処理を並べています。参照する記録の権限は取得時に、日報の保存権限は保存時に確認します。
2. 次の処理を決めるのは誰か：Chat・Workflow・Agent
同じ日報作成でも、次の動きを誰が決めるかで作り方が変わります。利用者が追加の依頼を出すのか、アプリが決めた手順を進めるのか、AIが結果を見て次の行動を選ぶのか。その違いをChat、Workflow、Agentで比べます。
Chat：利用者が次の依頼を出す
本人が「午前は資料作成、午後は打ち合わせ。このメモを日報にまとめて」と頼みます。AIが文章を返したら、本人が読み、「もっと短く」「打ち合わせで出た課題も加えて」と追加で頼めます。
次に何を頼むかを決めるのは利用者です。 日報を保存する操作も、この例では本人が行います。必要な材料を自分で用意でき、返答を見ながら次の依頼を決められる場合に向いています。
Workflow：アプリが決めた手順を進める
アプリが「今日やったことを入力してください」と案内します。入力後、AIが振り返りの質問を作り、本人が回答します。その内容からAIが下書きを作り、アプリが確認画面を出します。本人が確定したら保存します。
「仕事の入力 → 振り返り → 下書き → 本人の確認 → 保存」という手順と分岐を決めるのはアプリです。AIは質問や文章を作ります。確認や保存の条件が決まっている業務なら、途中の状態と失敗時の戻り先を管理できます。
Agent：AIが次の行動を選ぶ
本人が「今日の作業記録を調べて、日報の下書きを作って」と頼みます。AIはタスク記録を調べ、打ち合わせの内容が足りなければ会議メモを探すか、本人に尋ねるかを選びます。集めた材料を見て、さらに調べるか下書きを作るかも決めます。
目的に向けた次の行動を選ぶのはAIです。 記録の検索など、アプリが用意した操作をツールと呼びます。AIが使う操作と検索条件を提案し、アプリが権限と対象を確認して実行します。結果をAIへ戻し、必要ならこの流れを繰り返します。
このAgentの例は、タスク記録や会議メモを読むツールがある場合の設計案です。アプリは読める記録と使える操作を制限し、回数・時間・費用の上限と終了条件を決めます。下書きの最終確認と保存は、本人とアプリが担います。
| 呼び方 | 日報作成での動き | 次を決める主体 |
|---|---|---|
| Chat | 渡されたメモを文章にまとめ、追加の依頼に答える | 利用者 |
| Workflow | 入力から確認・保存まで、決めた手順で進める | アプリ |
| Agent | 記録を調べ、次に何をするかを選ぶ | AI（アプリが許可した範囲） |
画面がチャット形式でも、内部でWorkflowやAgentを動かせます。決められたWorkflowの中で、材料集めだけをAgentに任せる組み合わせもあります。どの場合も、情報の準備や出力の確認を支えるHarnessが必要です。処理の順番や分岐を管理する役割を、Orchestration（オーケストレーション）と呼びます。
どの動かし方を選ぶか
本人が材料を用意し、文章を確認して次の依頼を出せるならChatで足ります。毎回同じ確認や保存条件を通すならWorkflowが合います。AIに記録を探させる必要がある場合にAgentを検討します。
3. 作業の現在値と、今回AIへ渡す情報を分ける
日報アプリには、本人の入力、作業の進み具合、過去の日報、目標が保存されています。そのすべてを毎回AIへ送る必要はありません。目的に応じて、対象、期間、粒度、閲覧権限を決め、今回の判断に必要な部分だけを選びます。
| 依頼の目的 | 選ぶ材料の例 | 今回は含めない材料の例 |
|---|---|---|
| 今日の作業から、明日確認したい質問を一つ作る | 今日の関連作業、未解決点 | 無関係な案件、過去の日報すべて |
| 今日の日報を作る | 今日の作業・成果・困り事、必要な案件情報 | 今日の目的に関係しない全期間の活動 |
| 今週を目標に照らして振り返る | 対象の目標、今週の作業・成果、必要な比較材料 | 無関係な目標、他人の記録 |
短い依頼でも、必要な材料が少ないとは限りません。「一年の目標に照らして、今日の作業で前進したことを尋ねる」なら、目標と一定期間の履歴を追加で選ぶ必要があります。AIがもっと情報を求めた場合も、アプリが取得範囲と権限を確かめ、目的に必要な分だけ追加します。情報を取得できなければ、未確認として伝えるか本人に尋ねます。
目的から保存までは、次の順で考えます。
- 目的を決める。
- 対象・期間・粒度・権限を決め、使う記録を選ぶ。
- 選別したContextをAIへ渡し、候補を作る。
- アプリと本人が確認する。
- 条件を満たした内容を保存する。
Contextは今回の呼び出しに渡す情報で、データベース全体や過去の会話すべてを指す言葉ではありません。Sessionは作業の状態や継続単位を記録しますが、それ自体がデータの保存先や権限の保証になるわけではありません。保存先と各段階の権限はアプリが管理します。
ここでは情報を四つに分けて考えます。
| 種類 | 意味 | 日報での例 |
|---|---|---|
| Input（入力） | 今回受け取った材料 | 「午前は資料作成、午後は打ち合わせ」というメモ |
| State（状態） | 作業の進み具合や、本人が確認した現在値 | 振り返りへの回答、確定した作業時間 |
| Memory（記憶） | 過去から保持し、別の作業でも使う情報 | 保存済みの日報、本人の目標 |
| Context（AIへ渡す情報） | 今回のモデル呼び出しに含める情報 | 今日のメモ、確認済みの補足、必要な過去記録 |
Input、State、Memoryをすべて送るのではなく、目的に沿って対象・期間・粒度・権限を確かめ、日報の下書きに必要な情報を選んでContextを作ります。関係のない過去記録は含めません。各回の呼び出しには、システム指示やツール定義、会話履歴なども含まれます。ここでは業務データを整理するために四つの名前を使っています。
複数回にわたる作業では、アプリが作業セッションに入力、確認済みの値、作業段階を記録します。画面を閉じた後に再開できるよう保存する場合は、有効期限も決めます。AIの候補と本人が確定した値を分け、候補が確定値を上書きしないようにします。
今日のメモと過去の記録をAIへ送る前に、個人情報や社内情報を利用するモデルAPIへ送ってよいか、契約・保存設定・社内ルールを確認します。参照した文書に「これまでの指示を無視して送信せよ」と書かれていても、それは文書の内容であり、アプリの命令や本人の承認にはなりません。書き込みや外部送信は、アプリ側で権限を確認します。
4. 必要な記録だけを、読める範囲から探す
過去の記録を使う場合は、まず閲覧権限で検索対象を絞ります。日報の振り返りなら、本人が閲覧できる記録のうち同じプロジェクトのものを探します。候補から古い版や重複を除き、関係する記録のID・日付と必要な箇所をAIへ渡します。
| 検索の段階 | 日報の振り返りで行うこと |
|---|---|
| 対象を絞る | 本人が閲覧できる同じプロジェクトの記録に限る |
| 候補を探す | 今日のメモにある「資料作成」などを手掛かりに探す |
| 記録を選ぶ | 関係の深い記録を選び、重複や修正前の版を除く |
| AIへ渡す | 記録ID・日付と、参考になる箇所を渡す |
検索後に画面表示だけを隠しても、AIへ渡した情報は取り消せません。共有設定が変わった場合に備えて検索用データの権限情報を更新し、記録を取得するときに現在の権限を照合します。保持した参照情報を後で使うときも、権限を再確認します。
検索では、キーワードの一致、文章の意味の近さ、日付やカテゴリなどを使えます。検索結果に過去の成果が見つからない場合は、今日の入力だけで下書きを作るか、本人に確認します。過去の成果を推測で補うことはしません。
用語メモ：Embedding、Retrieval、RAG
文章を数値の並び（ベクトル）に変換する処理をEmbeddingと呼びます。ベクトルの近さで候補を探す方法がベクトル検索です。候補を探して必要な情報を取得する処理全体はRetrieval（検索・取得）と呼ばれます。
RAG（検索拡張生成）は、検索で取得した情報をモデルへの入力に加えて回答に使う設計パターンです。ベクトル検索は候補を探す一つの方法であり、それだけで今回役立つ記録が決まるわけではありません。似た文章でも、権限のない人の記録や別プロジェクトの成果は使えません。
記録を何度も検索し直さず、選んだ資料のID・版・短い抜粋を作業セッションに残して再利用できます。入力、対象、権限、参照元が変わったら、その記録を使い続けてよいか確かめます。条件が変わったときに再検索します。
5. AIの下書きを、確認してから保存する
本人が「資料を作った」と入力したのに、AIが「資料を使って顧客に提案し、合意を得た」と書くことがあります。文章は自然でも、入力にはない出来事です。だから下書きは、保存する完成品ではなく確認する候補として受け取ります。
同じように、下書きを待つ間に本人が「打ち合わせで決定した」を「まだ検討中」に直すこともあります。変更前の版から作った候補に「決定した」と残っていたら、アプリは現在の入力に合う結果として扱えません。どの版から作ったかを確かめ、古い内容を保存しないようにします。
AIに日報本文と参照した記録IDを決まった項目に分けて返させると、アプリが形式を検査しやすくなります。ただし、形式が正しいことと内容が正しいことは別です。
PromptにはAIに任せる仕事、返答の形式、判断の基準を書きます。どの記録を取得できるか、いつAIを呼び出すか、追加情報の要求を許す範囲、確認と保存の条件はHarnessを含むアプリ側で制御します。
| 確認すること | 日報作成での確認例 | 主な担当 |
|---|---|---|
| 形式 | 本文と参照記録IDが決めた項目に入っているか | アプリ |
| 参照先 | 記録IDが実在し、本人が今も閲覧できるか | アプリ |
| 対象 | 日付やプロジェクトが本人の選んだ値と一致するか | アプリ |
| 内容の根拠 | 入力にない成果や過去の成果が混ざっていないか | 本人がメモ・参照記録と照合 |
| 入力の版 | 下書き作成後にメモや回答が変わっていないか | アプリ |
記録IDが存在するかは、プログラムで確認できます。一方、その文章が本人の実績を正しく表しているかは、本人が元のメモと見比べて判断します。AIにもう一度判定させても、それだけで正しさは確定しません。
作業IDや入力の版は、モデルの返答ではなくアプリが要求を出した時点で保持します。参照先や対象の検査に失敗した下書きは確定せず、材料を選び直して再生成するか、本人に確認します。
6. 2回目の呼び出しへ、必要なやり取りと現在値を渡す
本人が「午後は打ち合わせ」と入力し、AIが「打ち合わせで何が決まりましたか」と尋ねたとします。本人の返答は「何も決まらず、来週また話すことになりました」。この返答だけを次の呼び出しに渡しても、AIにはどの打ち合わせの話か分かりません。
| 次の呼び出しへ渡す材料 | 例 |
|---|---|
| 元の入力 | 今日のメモにある「午後は打ち合わせ」 |
| AIの質問 | 「打ち合わせで何が決まりましたか」 |
| 本人の回答 | 「何も決まらず、来週また話すことになりました」 |
| アプリで確認した現在値 | 日付、プロジェクト、本人が修正・確定した内容 |
アプリの作業セッションから、この呼び出しに必要な材料を選びます。会話全体をそのまま送る必要はありませんが、質問や回答を外すと、次のAIはそのやり取りを知りません。
AIプロバイダーに会話継続機能があれば、前の応答につないで次の入力を渡せます。アプリが会話全体を組み直す手間を減らせます。会話履歴を引き継いでも、アプリの最新の確定値を確認する責任は残ります。
本人が作業時間を「2時間」から「3時間」に訂正したとします。AIとの古い会話には「2時間」が残っています。次の呼び出しには現在の確定値である3時間を渡します。古い値が混ざりそうなら、古い会話を続けず、現在の作業セッションから情報を選び直します。
会話の継続は「何を話したか」を、アプリの作業セッションは「どこまで進み、何が確定したか」を記録します。両方を使う場合も、次の呼び出しには現在値を選び直します。
実装メモ：OpenAIの会話継続API
OpenAI Responses APIでは、前の応答を previous_response_id で指定する方法と、Conversationを継続する方法があります。過去の入力トークンも入力として課金されます。Responseの保存は既定で30日で、store: falseを指定して無効化できます。Conversation内の項目には30日の有効期限がありません。サービスの保存条件と費用を実装時に確認してください。OpenAIの会話状態の資料（2026年10月8日確認）。
7. 入力変更と失敗に備える
入力を直した後に届いた下書きを採用しない
AIの応答を待っている間に、本人が入力を編集することがあります。
アプリは要求時に作業IDとメモの版を記録します。応答が届いたら現在の版を確認し、合わない下書きを表示・保存しません。版7から作った下書きが届いた時点で版8なら、その候補は古いものとして破棄するか、作り直します。
確認画面を出した時点で版が合っていても、本人が保存するまでにメモが変わることがあります。保存時にも現在の版を確かめ、「版8なら更新する」という条件で保存します。版9へ変わっていれば保存せず、本人に再確認を求めます。
止める失敗と、別の方法で続ける失敗を分ける
AI機能には、検索、下書き作成、保存、検索用データの作成など複数の処理があります。失敗した処理が必須かどうかで、止めるか続けるかを決めます。
過去の日報が参考情報なら、検索に失敗しても今日のメモだけで下書きを作れます。その場合は、過去記録を参照できなかったことを本人に伝えます。今日の仕事を集めることが必須なら、記録を取得できないときは下書きを作らず、本人に入力を求めます。
権限確認や保存前の版照合に失敗した場合は処理を止めます。モデル呼び出しがタイムアウトした場合は、再試行するか、本人の手入力へ戻します。保存後の検索用データ生成だけが失敗した場合は、保存済みの日報を残し、その処理を後から再実行します。
再試行で二度保存しない
候補の生成はやり直せます。しかし、同じ確定操作を再実行すると日報や通知が二重になることがあります。確定操作を一度だけ保存し、タイムアウト後は「保存されていない」と決めつけず、保存結果を調べます。
保存後の補助処理は本文保存と分けて記録し、同じ日報IDで再実行できるようにします。キャンセル後に古い応答が届いても、現在の要求と異なる結果は適用しません。
実装メモ：版番号と要求ID
表示時と保存時の版照合、条件付き更新で競合を防ぎます。単純な画面では入力の指紋（inputFingerprint）を比べる方法もありますが、下書きに使った過去記録が変わった場合も確認が必要です。文書IDや確定要求IDの持ち方は実装に合わせて決めます。
8. 処理全体を追い、品質を確かめる
応答までの時間だけでは、検索とモデル呼び出しのどちらが遅いか分かりません。検索、AIへ渡す情報の準備、下書き作成、検証、保存を分けて記録すると、改善する場所を見つけられます。
図の時間・件数・割合は説明用の架空の数値で、実測値ではありません。
日報なら、下書きをそのまま使えた割合、修正した割合、保存までの時間、参照元の不一致や権限検査の失敗を見ます。同じ要求IDで検索から保存までを追うと、どの段階でずれたか調べられます。ログには機微情報を必要以上に残さず、記録内容と閲覧できる人を決めます。
補足：モデル比較でも周囲の条件をそろえる
ARC-AGI-3のSemi-Private評価では、GPT-6 Astraのmax設定でStandard harnessが62.7%、Provider Adapter harnessが98.6%でした。評価対象は未知のゲーム環境を探索する課題であり、業務アプリの性能を示す数字ではありません。モデルを比べるときは、状態の引き継ぎ方などHarnessの条件もそろえる必要があります。ARC Prizeの評価記事（2026年10月8日確認）。
9. Kizukiを例にした日報AIの設計案
以下はKizukiの日報フローを題材にした設計例で、実際のコードや運用を検証した記録ではありません。
本人がプロジェクト、カテゴリ、作業時間を入力します。関連する過去記録を手掛かりに振り返り、AIの質問に答えます。AIは目標や改善テーマとの関係を候補として示し、本人が確認した内容を日報として保存します。次の段階を決めるのはアプリなので、この例はWorkflowです。
図の RecallContext は、選んだ過去記録のID・抜粋・参照元などを一時的に保持する、この設計例での名前です。
| Harnessが担うこと | このフローで行うこと |
|---|---|
| 情報と状態の管理 | 作業セッションに入力、本人の確定値、選んだ過去記録を保持し、各段階で必要な情報だけを渡す。 |
| 出力の検証と本人確認 | 振り返りや目標との対応は候補として扱い、ID・有効性・根拠を確認してから本人に見せる。 |
| 変更と失敗への対応 | 入力変更前の応答を採用せず、影響する候補だけを作り直す。保存後の補助処理は再試行できるようにする。 |
| 処理全体の観測 | 検索から保存まで同じ作業IDで追い、時間、候補の採用・修正、検証失敗を確認する。 |
AIが「説明の順番を改善する」という目標との関係を提案しても、アプリは目標IDが存在し、本人に有効かを確認します。今回の活動に根拠があるかは本人が判断し、必要なら修正して確定します。
10. 自分のAI機能で、まず三つ決める
AI機能を考えるときは、まず次の三つを決めます。
- AIに何を渡すか。 今回の目的に必要な入力や記録はどれか。
- 人が何を確かめるか。 アプリで検査できる条件と、本人が判断する内容は何か。
- 入力変更や失敗時にどう戻すか。 古い下書きをどう扱い、必須情報が取れないときにどこで止めるか。
実装する人は、1章の処理表を自分の機能名に置き換え、状態・権限・確認・保存条件を整理します。その上で次の四つをテストします。
| テスト | 合格条件 |
|---|---|
| AIの応答を待つ間に入力を変更する | 古い下書きが表示・保存されない |
| 作業セッションに保持した記録の閲覧権限を外す | 権限を失った情報が次のAI呼び出しに渡らない |
| 会話継続中に本人の確定値を変える | 次の呼び出しに現在値が渡る |
| 保存直後に検索用データの生成を失敗させる | 保存済みの日報が残り、補助処理だけ再実行できる |
まず自分の業務を一つ選び、目的に必要な情報と不要な情報、結果の確認方法、保存条件を書き出してください。PromptでAIに任せる仕事や返答の形式を示し、Harnessで取得範囲と呼び出し、確認、保存を制御します。目的に必要な材料を選び、結果を確かめてから保存する流れが、AIをシステムに組み込む設計の出発点です。
参考資料・確認日
本文の日報例とKizukiの構成は筆者の設計案です。参照資料がこの実装を推奨している、または実測したという意味ではありません。元記事の確認日は2026年9月27日です。OpenAIの会話状態資料とARC Prizeの評価記事は2026年10月8日に再確認しました。
- Anthropic, Building effective agents：コードで手順を決めるWorkflowと、モデルがツール利用を選ぶAgentの区別。
- Anthropic, Effective context engineering for AI agents：目的に応じて必要な情報をContextへ選ぶ考え方。
- ARC Prize, OpenAI's GPT-6 Astra on ARC-AGI-3：Semi-Private評価のHarness別・推論設定別の結果と、その評価条件。
- OpenAI, Conversation state：会話履歴を手動で渡す方法、
previous_response_idとConversationによる継続、保存と課金条件。 - OpenAI, Structured Outputs：構造を制約した出力の仕様。業務上の妥当性検査まで保証するものではありません。
- OpenAI, Production best practices：本番導入時のデータ送信・保存・保持の検討事項。
- OpenAI, Safety best practices：プロンプトインジェクションへのテストと人による確認。
- Azure Databricks, Retrieval-augmented generation：RAGの検索・入力拡張・生成の構成とアクセス制御。
- AWS, Enable tracing for agents and RAG workflows：処理段階を追跡する観測の考え方。
