ハーネスエンジニアリング

うまくいかないときに、どの層を直すかの切り分け

ARCHECOは失敗の記録から、指示・情報・実行の仕組みのどこを直すかを決めます。意図が伝わらないのか、判断材料が足りないのか、実行や検証の仕組みがないのかを分けます。情報不足や引き継ぎの欠けは、頼み方を磨くだけでは直りません。OpenAIも、行き詰まったら「もっと頑張れ」ではなく、不足する道具や文書を問うとしています。

失敗は、足りない環境の手がかりになります。NTTデータは、コマンドを知らない失敗と、仕様の所在を見つけられない失敗を分けています。NTTデータは、テストを実行しない失敗や、変更禁止の範囲に触れた失敗も別の型として扱っています。ARCHECOは下表で振り分け、同じ失敗に効く制御を作ります。

繰り返す注意は、早く自動で検査できる場所へ移します。＠ITが紹介するGoogleの解説で、OpenAIの実践報告を書いたライアン・ロポポロ氏が述べるシフトレフト（確認を工程の前のほうへ移すこと）の考え方です。担当者が繰り返す注意を文書に残し、機械で判定できる決まりをリンターに移します。リンターはコードの書き方を自動検査する道具です。さらにテストや実作業に入る前の評価問題（AIの出来を測る試験問題）で確かめると、人が毎回注意する負担を減らせます。下表で症状を選び、続く導入例で設定と合否の確認方法を見てください。

御社の症状から、診断で調べる場所を選ぶ

ARCHECOは症状に応じて、まず次の記録を照合します。初回は機密を含まない症状の概要と、使っているAIの名前だけで構いません。記録は秘密保持の取り決めのあとに伺います。

AIが止まる場合は、停止時の進捗と検査の記録を照合します。意図を取り違える場合は、依頼の原文とAIへ渡った資料を照合します。

成果物を確かめきれない場合は、完了報告と検査結果を照合します。許可外の操作が起きた場合は、許可した範囲と実行記録を照合します。

既存CIがあるチームでの進め方（説明例）

症状に対して何を設定し、どう合否を確かめるかを、既存の検査を使う例で示します。

無料診断でお返しするものの見本

対応表で選んだ症状から、最初に調べる場所を整理します。自社検証を題材にした見本と、症状表を使った診断の説明例を示します。

ハーネスエンジニアリングの定義

ハーネスエンジニアリングとは、AIモデルの外側の仕組みを設計し、作り、直し続けることです。AIエージェントは、指示を受けて手順を考え、道具を使い、結果を確かめて作業するAIです。設計する人が、AIに渡す指示・情報と、使える道具・操作の範囲を決めます。AIの進捗を保存する仕組みに、結果の検証と操作の記録、人への差し戻しを組み合わせます。モデルの再訓練ではなく、賢さを仕事に変える環境を作る活動です。

作った後も、失敗から環境を直し続けます。QiitaやAIsmileyの解説も、テストの自動化やCI、権限管理と監視をAI向けに組み直すものと説明しています。CIは変更のたびに自動で検査する仕組みです。人の開発者と同じく、AIの成果物にも点検（レビュー）とテストが必要です。設計者は、AIが結果を確かめ、誤りを直せるように検査を組み込みます。

呼び名は、作る行為と作られた物を分けると理解できます。AIハーネス・エージェントハーネス・LLMハーネスは仕組みそのものです。LLMは大規模言語モデルで、ChatGPTやClaudeの頭脳にあたります。作る行為は英語で harness engineering と書きます。評価ハーネスはモデルの成績を試験で測る別の仕組みです。ハーネスは製品名や、開発用の部品集であるフレームワークの名前ではありません。Claude CodeやCodexには一部が組み込まれ、使う側がルールや権限を足します。

語源のハーネスは、手綱や鞍、引き具などの馬具を指します。AIの分野では、モデルの能力を仕事に使うための仕組みを指す名称です。登山の安全帯や配線を束ねるワイヤーハーネス、試験用のテストハーネスとは用法が異なります。ここからは、AIモデルと周囲の仕組みの役割を分けて説明します。

「エージェント＝モデル＋ハーネス」という考え方

エージェントは、モデルに仕事のための仕組みを足したものとして捉えます。LangChainのVivek Trivedy氏は2026年3月10日に「Agent = Model + Harness」と示しました。解説名は「The Anatomy of an Agent Harness」です。「If you’re not the model, you’re the harness.（モデルでないものは、すべてハーネスだ）」は、モデルでない部分をすべて含める広い定義です。

モデル単体には、作業の記憶を保存し、仕事を続ける手段が足りません。会話を越えた記憶の保持や、ファイル・コマンドの直接操作には周囲の仕組みが必要です。自分の出来を確かめる手段もありません。設計者は、AIが指示を読み、道具を呼ぶ仕組みを足します。次に状態の保存、検証、記録をつなぐと、AIモデルが仕事を進めるエージェントになります。Google DeepMindのPhilipp Schmid氏も、モデルを包み、長時間の作業を管理する土台と定義しています。

役割を整理した既存の説明に、パソコンの構成との対応があります。モデルは計算を担うCPU、一度に読める会話の量は記憶領域のメモリに対応します。道具は周辺機器を操作する部分、ハーネスは全体を管理する基本ソフトのOSです。エージェントは、その上で動くアプリに対応します。元は2023年のBeren Millidge氏の比喩とされます。CodeZineの西見公宏氏は、文脈管理をOSのメモリ管理に対応させています。道具の実行管理は入出力管理、作業の計画はプロセス管理です。

ARCHECOは、モデル交換の前に不足する仕組みを数えます。＠ITが紹介するGoogleの解説（2026年9月25日の紹介）で、スミタ・コラン氏はモデル・ハーネス・知識の釣り合いを重視しています。まず道具や判断材料を確かめることで、モデルを替える以外の打ち手を選べます。直す対象は、指示の文面・判断材料・動作の仕組みに分けると整理できます。

プロンプト・コンテキストエンジニアリングとの違い

違いは「どう頼むか」「何を見せるか」「どう動かして確かめるか」です。プロンプトエンジニアリングは、AIへの指示文を整える仕事です。担当者が役割や出力形式を指定し、手順・例題を使って文面を磨きます。コンテキストエンジニアリングでは、AIの判断材料となる背景・ルール・参照資料の渡し方を設計します。量と形式を決め、読む順番とタイミングを整える仕事です。ハーネスはその情報を使う道具に権限を与え、検証・復旧・引き継ぎまで扱います。

選ぶ基準は、指示を伝えるだけで足りるか、仕組みで守らせる必要があるかです。単発の文章作成や対話はプロンプトが中心です。長時間の作業や道具の使用、チームの運用ではハーネスが要ります。プロンプトは不要にならず、ハーネスの中で使い続けます。成果物も異なります。Qiitaの比較では、プロンプトは指示の雛形、コンテキストは資料検索や例題の設計です。ハーネスは進捗ファイル・機能一覧・自動検査の設計です。冒頭の対応表は、この違いに沿って症状と直す場所を分けています。続いて、作る速さと確かめる速さの差を見ます。

ハーネスエンジニアリングで、作る速さに確かめる速さを合わせる

ARCHECOは、AIが作る量を増やす前に、検証と承認にかかる負担を確かめます。ファインディの2026年4月の国内調査はエンジニア157人が対象でした。AIで改善を実感した割合は、コーディング87%に対し、品質検証44%、リリースと運用41%です。同社の開発組織トレンド調査2026では、AI駆動開発を重要と考える割合は65.7%でした。本番運用の割合は40.0%にとどまります。この差は調べた15項目で2番目に大きいとしています。ARCHECOは、作成量だけでなく確認待ちと差し戻しを見ます。

長い仕事をAIに任せるほど、人が全部を読む前提は難しくなります。AIの使い方は、チャットや1行ずつの補完から、調査→修正→テスト→報告へ広がりました。Software Design誌は、ソフトウェアの実課題を解く試験「SWE-bench Verified」の推移を紹介しています。Anthropicモデルの最高点は、2024年10月の49%から2025年11月に80%へ上がりました。自走時間も数十分から数時間〜数日へ延びています。OpenAIでは、エンジニアが寝ている間にAIが6時間以上動くことが日常でした。作業が長いほど誤りは後へ伝わり、途中経過は会話から消えます。OpenAIが希少な資源とした、人の時間と注意力を検証にどう配るかが課題です。

Software Design誌は個人の見解として、AIの進歩について発信するSimon Willison氏がOpus 4.5とGPT-5.2の出た2025年11〜12月を転換点としたことを紹介しています。同じくAIの進歩について発信するKarpathy氏も2025年12月を境に、長い作業の粘り強さが上がったと述べています。

個人の工夫は、チームで繰り返し使える場所に移します。会話履歴に閉じた知識では、担当が替わるたび同じ失敗が起きます。担当者はルール・手順を、コードと履歴を保存するリポジトリや共通の保管場所に置きます。誰が何を変えたかも記録します。Googleの研究プログラムDORAは、AIが組織の強みも弱みも増幅すると説明しています。OpenAIでは、各担当者のAIが、共有されたルールや手順を使って作業できました。人数が3人から7人に増えても、1人あたりの処理量が上がりました。

技術の外の決まりも、運用に合わせて見直します。道具が毎週変わる一方、社内の決まりが年に一度しか変わらない場合があります。検証と統制が追いつかないまま作成量を増やすと、確認待ちと危険が増えます。ARCHECOがハーネスと人・組織の備えを一緒に扱う理由です。

同じモデルでも、ハーネスエンジニアリングで成績が変わる

ARCHECOは、モデルを替える前に、周りの仕組みの不足を切り分けます。同じモデルでも成績が変わる公開例がありますが、仕組みを足せば必ず良くなるわけではありません。導入先の作業で、足す前と後を比べることを前提にします。

ハーネスだけの改善で、成績が上がった例があります。日本HPは、LangChainがモデルを固定し追加学習せずに改善した例を紹介しています。端末操作の課題を解く試験「Terminal Bench 2.0」で、成績は52.8%から66.5%へ上がりました。13.7ポイントの改善で、順位は30位圏外から5位以内に入りました。同記事が引くAIエージェント開発のHumanLayer社の報告「Skill Issue」の順位では、Claude Opus 4.6がClaude Code上の約33位から、別のハーネスで5位になりました。ブログBSWENの整理にも38%から60%へ22ポイント動いた例があります。ただし日本HPは、BSWENの数字は論文でなくブログの整理だと断っています。

モデルの比較だけでは見えない差もあります。サーバーワークスはSWE-benchの分析で、上位モデルの入れ替えによる差はわずかだったと紹介しています。ASPICはスタンフォード大学の研究「Meta-Harness」で、数学の正答率が4.7ポイント上がった例を挙げています。いずれも、御社の業務で同じ差が出る根拠にはなりません。

足しても効かなかった結果も、設計に反映します。電通総研は、銀行の取引や残高を処理する勘定系システムを題材に検証しました。Opus 4.8とHaiku 4.5で基本は各3回、点検役の比較だけ5回試しています。AIに見せない隠しテストで採点した結果です。効いたのは状態の引き継ぎと、正しい資料の手がかりです。再実行・完了前のフック・スキル（必要な作業のときにAIへ読ませる手順書）は、不合格0件のままで差が出ませんでした。フックはHaikuの手数を18回から49回へ、費用を約3倍へ増やしました。別のAIによる点検が効いたのはHaikuだけです。詳細は下表に残します。

フックと検収は、必要な失敗を防げるかで選びます。電通総研は、今のAIが自分で再実行や型検査（データの種類の整合性を確かめる検査）をすることを、差が出なかった理由に挙げています。ARCHECOが重視するのは、本番反映や支払いを止め、長い作業で報告と実物のずれを見つけることです。短く閉じた課題と、外部サービスや長時間作業では条件が違います。まず素の構成で試し、不足した情報と制御だけを足します。不足する仕組みを探す際は、製品に内蔵された部分と御社が整える部分を分けます。

内部ハーネスと外部ハーネス：ARCHECOが整えるのは使う側

ARCHECOが整えるのは、使う側が育てる外部ハーネスです。AI製品の中で判断・道具の使用・結果の確認を繰り返す仕組み（実行ループ）や、道具の呼び出しは、作り手が組み込む内部ハーネスです。製品を導入するだけで、御社固有の判断や承認の基準まではそろいません。

設計を頼む前に、製品と使い手の担当範囲を分けます。Software Design誌は、LangChainやAnthropicを作り手側の議論として紹介しています。ThoughtworksのBirgitta Böckeler氏、失敗ごとの環境改善を発信するMitchell Hashimoto氏、OpenAIは使い手側の議論と整理しています。普通の会社が育てるのは後者で、ユーザーハーネスとも呼ばれます。AIを動かすプログラムの部品一式であるClaude Agent SDKやClaude Managed Agentsのように、内部の仕組みを部品やサービスとして公開する動きもあります。

使う側では、ルールファイルと権限を定め、フックで操作を検査します。さらに検証と記録を整え、人と組織の備えを合わせます。ARCHECOは、特定製品への作り込みより、選んだ製品の上で組織の基準を実行できることを確認します。使う製品が更新されても残すべき基準を、次に整理します。

モデルが賢くなると、何が古くなり何が残るか

ARCHECOが残すべきと考えるのは、組織ごとに異なる知識と判断基準です。速さと安全のどちらを優先するか、費用をかけて時間を短縮してよいかは、組織ごとの判断です。モデルが外から知ることはできません。

電通総研も、知能を肩代わりする工夫より、知識を補う工夫が価値を持ち続けると述べています。

モデル更新時には、以前必要だった仕組みを外せるかも試します。Anthropicには、会話の文脈をいったんリセットする仕組みを、次のモデル世代で外せたという報告があります。＠ITが紹介するGoogleの解説でも、独自ハーネスの作り込みすぎを避け、道具と文脈の質への投資を勧めています。既製部分の再実装を増やさず、組織固有の部分を保守します。

今後の予想は、実績と分けて扱います。ASPICは、モデル間の差が縮むほど環境で差がつき、AIが記録からハーネスを書き換える仕組みが広がると予想しています。一方、OpenAI自身も、AIだけで作った設計の一貫性が何年保てるかは未確認としています。自動の改善にも履歴と評価を付け、古いルールを消す運用を残します。組織固有の基準を実行に反映する場所が、次の7つの仕組みです。

症状に合わせて選ぶ7つの仕組み

ARCHECOは、AIが困った場面から直す場所を決められるよう、7つに分けています。番号と名前は、1. ルール、2. 道具、3. ガードレール（危険な操作を止める仕組み）です。作業の継続を支えるのは、4. 止まらない仕組み、5. 安全な環境です。結果の確認と復旧を担うのは、6. 検収、7. 事故への備えです。前の症状別の対応表で選んだ修正箇所を、以下の各項目で具体化します。各項目ではARCHECOが作り、御社へ渡すものを示します。他の分類との対応は、ページ末尾の「参考：他の分類と7つの仕組みの対応」で確認できます。

1. ルール：AIが組織のルールに沿って働く

まず、ARCHECOはAIが判断の前提として読むルールから整えます。依頼の原文と組織のルールを、AIに渡せる形にします。自社検証では、要約で依頼の目的が消え、AIが別のアプリを磨いていました。依頼の原文（要約する前の元の文面）が残っていたため、AIに作り直す方向を伝えられました。組織の決まりも、人の頭やチャットにしかなければAIからは見えません。新しい担当者に渡すのと同じく、毎回読める場所に置く必要があります。以下では、入口のルールを短く保ち、機械で守るものを分け、判断の型と手順を渡します。ARCHECOはルールと強制手段の対応表を作り、同じ取り違えや違反を防げるか確かめます。

2. 道具：AIが使う道具と情報を整える

ルールを実行できるように、ARCHECOはAIが使う道具と計算資源を整えます。自社検証では、2体のAIがメモリ18GBのMacを使い、記憶領域の不足分を補う退避領域が最大30GBに膨らみました。AIは同時実行を防ぐ制御を自作し、重い処理を順番に動かしました。AIの能力だけでは、使う資源や道具の競合を解消できないためです。以下では道具を絞り、画面と記録を読めるようにし、製品ごとの設定を確かめます。ARCHECOは必要な接続と道具を整え、正常時だけでなく故障時の応答も試します。 道具を接続するSDKとは、AIを動かすプログラムを作るための部品一式です。以下の製品別の設定名や既定値は、実装担当者向けの参考情報です。

3. ガードレール：越えてはいけない線で止める

道具を渡すときは、AIに許す操作と、止める操作を先に決めます。ARCHECOの自社検証では、最初に音を止めたとき、AIが名前の合う実行中のプログラムをまとめて終了させました。別のAIが同時に動いていれば、その作業も巻き込むおそれがありました。AIは自分で危険に気づき、以後は自分の作業フォルダのプロセス（実行中のプログラム）だけを止める、と記録しました。2回目は代表の会議中に音が鳴り、代表が「止めて」と送ってから数分で音が止まりました。 善意の操作でも対象を広く取りすぎれば、別の作業を巻き込みます。権限と承認の境界を、実行する前に決める必要があります。以下では操作前のフック、権限の評価、承認と検査、構造の決まりを設計します。ARCHECOは承認者と止める条件を設定し、許可した操作だけが通るかを試します。

4. 止まらない仕組み：分かれ道で判断し、作業を続ける

操作の境界を決めたら、許可した範囲でAIが作業を続けられるようにします。ARCHECOの自社検証では、動画アプリを担当するAIが重い処理の順番を3回続けて待ちきれず、停止しました。利用枠やアプリの再起動でも止まりますが、この記録の停止の多くは次の選択を決められない場面でした。継続には、再起動だけでなく判断の基準が要ります。以下ではAIの判断基準を決め、試行回数などに上限を設けます。進捗と役割を次の作業へ引き継ぐ方法も示します。ARCHECOは見回りと再開の仕組みを作り、承認待ちでは止まり、許可の範囲では続けられるか確かめます。見回り役が依頼者を待たずに判断した件数は、音楽アプリで10件、動画アプリで19件です。判断の記録は、下の「自社検証での制限と判断の記録」に示します。

5. 安全な環境：権限を絞り、作業場所を隔離する

AIの作業を続ける間も、データと作業場所を保護する必要があります。ARCHECOの自社検証では、試聴ページを合言葉で保護しました。無料枠を使い切った場合も、保護を残したまま配信を止める設定にしました。以下では作業場所を隔離し、AI専用の権限と秘密の置き場所を決めます。ARCHECOは承認された範囲に環境を絞り、範囲外への書き込みや秘密の混入を検査します。

6. 検収：成果物を別の目で確かめる

安全な作業場所で作った成果物も、「完成」という報告だけでは受け入れません。ARCHECOの自社検証では、AIの報告書に4つの作業が「後回し」と書かれており、まとめ役のAIが差し戻しました。自己申告と、合意した完了条件を確かめる検査は別だからです。以下では自動検証と点検役を分け、完了の基準と定期的な手入れを決めます。ARCHECOは検収の手順を作り、残件を含む報告と実物を照合します。機械で判定できない品質は、人の確認として残します。

7. 事故への備え：記録を残し、戻し方を確かめる

検収で見つけた誤りや運用中の事故に備え、ARCHECOは変更前の状態と復旧手順を残します。ARCHECOの運用記録では、誤って変更した外部サービスの設定を、変更前の記録から戻せました。事故の影響を抑えるには、小さいうちに気づき、戻せる状態を保存する必要があります。以下では操作の記録、復旧の手順、ハーネス自体の変更管理を整えます。ARCHECOは対象ごとに戻し方を作って復旧を試し、戻せない影響と責任者も明確にします。すべての事故が同じ時間で戻るとは約束しません。

1. 出島：変革を担う組織・場を、本体の外に設ける

社内の決まりが道具の更新に追いつかないと、使えるAIや処理の場所で作業が詰まります。生成AIサービスのClaudeを使う会社も、CopilotやGeminiに限る会社もあります。ARCHECOの自社検証では利用枠に応じてAIを替えましたが、企業では同じ変更にも承認が要ります。

出島で試す場合も、情シスや法務の承認を前提にします。ARCHECOは御社と対象データ・責任者を先に決めます。操作記録の残し方も合意します。外に出さないデータ、処理の場所、記録に残さない情報を定めます。通信方式と接続先も、会社の決まりと同じ水準で守ります。御社の決まりに沿って試せる範囲を先に確定するためです。

出島の置き場所は、御社の承認のもとで決めます。組織を本体の外に切り出すことと、データを社外に置くことは別に判断します。ARCHECOは御社と、管理担当者と責任範囲を着手前に決めます。データを外に出せない場合は、外へ送信しないモデルや閉じた環境を選びます。社内へ成果を取り込む際は、承認を得たファイルを受け渡す手順を設けます。

自社検証では、曲を生成するモデルを手元のMacで動かしました。公開記事の記録では、曲の生成の指示と生成データは手元の外へ出していません。これは曲の生成工程についての記録です。配信は別の工程で、外部の配信先の無料枠を確認して選んでいます。

御社の出島では、ARCHECOが御社と、どのデータを使うかを先に決め、送信先を限ります。生成・開発・配信の工程ごとに、処理場所と接続先を確認します。

社内への取り込みには、ARCHECOが次の手順を設計します。まずARCHECOが、生成コードと受け渡すファイルに秘密情報が含まれないか検査します。外部の部品（依存パッケージ）は、配布元と用途を確認して妥当性を判断します。既知の脆弱性と危ない書き方も自動検査し、結果を記録します。次に御社の情シス・法務が、安全性とデータの扱い、ライセンスなどの権利を確認します。承認を得たファイルをARCHECOが検証環境へ取り込み、既存の検査と受け入れ条件で確かめます。既存のデータ構造や連携を壊さないことも、取り込みの条件として検査します。本番への反映は、その結果に対する御社の承認後に進めます。社内の決まりを更新する判断材料まで整える支援です。実行の場を用意しても、人にしかできない操作は残るため、担当者を決めます。

2. 人の担当：AIにできない操作と承認を引き受ける

人に残す操作は、担当が決まっていないと全体の待ち時間になります。ARCHECOの記録でも、作業フォルダを信頼してよいかを尋ねる確認画面は、人が操作しました。既定の選択肢が「いいえ、終了」だったため、自動応答ではAIが終わってしまいます。iPhone実機にはケーブル接続が要り、管理者パスワードを必要とする点検は、人の操作を2日以上待ちました。

承認と作業の役割を分け、待たせず引き受ける担当を置きます。ARCHECOは、本人確認と物理操作を人の担当にします。支払いと最後の承認も、人が引き受ける操作として残します。業務担当者が正解と承認の条件を決め、エンジニアが仕組みに落とします。OpenAIの報告でも、人の役割は優先順位を決め、利用者の声を受け入れ基準にし、成果を確かめることへ移りました。

ARCHECOは、人に残す操作の担当表と承認の境界を整えます。開発と検証が速くてもリリースが増えなければ、詰まりを移しただけです。人の待ち時間を測り、どの担当で止まるかを見直します。担当を置くことに加え、AIへの指示と結果の判断を実務で練習する必要があります。

3. コーチング：使う人の判断と伝え方を磨く

指示の方向とタイミングがずれると、AIは速く作っても意図を外します。ARCHECOの記録では、依頼者が方向を直し、音を出してよいと決まりを変えたことが結果に影響しました。コーチングでは、御社の担当者が何をいつAIに伝え、どの判断を任せるかを、実際の仕事で練習します。

ARCHECOは、社員が実務で使えるまで伴走して教えます。人の仕事は、AIが動く環境を整え、目的を明確にし、結果を返して改善する手順を設計することへ変わります。実務で合意した判断基準は、個人の経験にとどめず、組織のルールとして残します。

身につける力は、目的から検証までをつなぐ力です。renueは出力を見る目と作業の分割に加え、フィードバックの設計と限界の見極めを挙げます。ブレクサは目的の明確化から情報の構造化へ進み、権限と境界を決める力を挙げています。さらに成果を機械で確かめ、失敗から環境を直す力を重視します。知識だけでなく、型と慣れが必要です。

参考：判断基準を合意する研修の例です。研修では、結果を比較して判断基準を合意する練習ができます。VOIXが紹介するジェネラティブエージェンツの講座は「AIコーディング実践講座・アドバンス」です。開発の責任者向けに1日で講義と実習を行います。3〜4人の班がブラウザの「ハーネスラボ」で指示を直し、結果から改善点を合意します。

参考：＠ITが紹介したGoogleの解説動画では、ロポポロ氏（同記事では現Google Cloud所属）が2025年5月以降、編集画面を開いていないと語っています。同氏が見ているのは、変更や文書が組織の基準を満たすかです。出典は、2026年9月25日のGoogleによる動画の紹介を要約した＠ITの記事です。実務で確認する対象が、作業そのものから組織の基準へ移った例です。

4. 組織のルール：社内の決まりをAIが読める形で育てる

決まりが人の頭や古い文書に残ったままでは、AIは従えません。ARCHECOのAIたちが守っているルールは、ほとんどが事故から生まれたものです。パソコンのデスクトップやディスプレイの切り替えは人に任せ、AIには機密データを変更履歴へ入れさせません。本番への反映と支払いには、人の言葉による許可を求めます。別のAIからの連絡は、人の許可として扱いません。どれも一度ひやりとしたあとに書き足しました。ルールは最初から完璧には作れず、AIが読める場所に書かれていなければ働きません。

企業ではここに統制が加わります。NTTデータの解説が「運用」として整理しているとおり、AIが書いたものでも説明する責任は会社に残ります。要件と判断の担当を記録し、検証した内容と承認者を残します。その記録を既存のセキュリティ審査や監査へつなぎます。変更管理とリリース判定も同じ手続きに合わせます。AIに入力してよい情報の範囲、個人情報の扱い、依存する外部の部品の危険の確認も決めます。

組織の運用担当は、AIエージェントの所有者・目的・IDを台帳に記録します。権限と接続先も管理し、使わなくなったAIを廃止する手順を設けます。境界は中央で決め、境界の内側の自由は現場に任せるのが、多くの解説とARCHECOに共通する考え方です。ARCHECOは、御社の承認手続きとAIの記録をつなぎ、書き足す担当と見直しの場を整えます。ルールの更新時には、使うモデルや道具の条件も確かめ直します。

5. 選定：モデル・道具・置き場所を選び続ける

道具を選んだまま放置すると、利用枠や権利の条件が作業を止めます。ARCHECOの記録も、選び直す場面の連続でした。AIは曲を作るモデルの権利条件を比べ、3つの候補から選びました。実装を任せるAIは、処理できる文章量であるトークンの残りを見てClaudeからCodexへ切り替えました。配信先は、無料枠が1ファイル25MiB、1日10万リクエストであることを確認して選びました。MiBはファイル容量の単位、リクエストは配信先への要求の回数です。選ぶモデルや道具によって、費用・権利・速さの条件が変わります。担当者は、更新に合わせて選定を見直します。ARCHECOは毎朝6時にAIの道具の更新を調べる仕組みを動かしており、自社検証を行った10月24日の朝も、使っている道具の1つが新しい版に上がっていました。

ハーネスを自分で作るか、既製の部品やSDKに任せるかも選定の一部です。一創は、監査で振る舞いを確定させる必要があれば自作を勧めています。契約上、特定の会社に依存できない場合も同様です。それ以外は既製の部品から始めるとしています。自作する場合も、業務に固有の道具と承認・検査の部分に絞り、異常終了や承認の拒否まで試すテストを用意します。部品集の向き不向きは下の表のとおりです（AIsmileyの解説をもとに整理）。

モデルは、任せる作業で品質と負担を比較して選びます。電通総研は小さなモデルのHaikuでも、差がつく課題を作るのに苦労したと報告しています。その結果から、小さな修正は軽いモデルに任せてみることを勧めています。＠ITが要約したGoogleの解説動画でも、スミタ・コラン氏が、コーディングのエージェントに重い推論モデルが必ず要るわけではないと述べています。半年前にできなかった作業が今のモデルならできることもあるので、できなかった作業は定期的に試し直します。

ARCHECOは比較表を作り、導入と更新を支援します。道具を替えるだけで解決とせず、御社の作業で判断と検証が成立するかを試します。必要な仕組みと担当を選んだ後は、小さく試して効果を測ります。

ハーネスエンジニアリングの進め方（導入の手順）

ARCHECOは最初に失敗の原因を整理し、御社と役割を分けて進めます。一般的な「ルールを書く→検査を入れる→記録で直す」の前に、棚卸しを置きます。過去の失敗と毎回伝える注意を集め、知識の置き場所と入力してよい情報も確かめます。7つの仕組みと組織の5つの備えに振り分け、下表の段階ごとに作るものを決めます。

ARCHECOは、前半と同じ4段階で、棚卸し→設計と実装→人と組織の整備→運用へ進めます。段階2では、守る境界と完了条件の合意→検査・権限などの実装→検収・復旧の確認の順に進めます。実装する部品の順番は、既存の検査と権限の状態で変えます。すでにルールや検査がある会社は、文章の指示をフック・権限・テストへ移す段階から始められます。参考として、Software Design誌は検査→権限→ルールファイルを勧めています。ARCHECOも、守る境界を確認してからAIに作業を任せます。

導入後も、事故と停止のたびに仕組みを1つずつ直します。毎月「今月の失敗と、それをどう防ぐか」を見直します。同じ失敗を繰り返さないよう、運用担当者が改善をルールや検査として残す方法です。足すたびに確認する担当と方法を決め、負荷が増えすぎていないかも見ます。

設計の点検では、完了条件から緊急停止まで、AIの作業全体を確認します。ブレクサの7つの問いも、確認項目として使えます。まず完了条件と必要な道具を確かめ、権限が操作単位で最小かを見ます。次に状態が会話の外に残り、外の基準で検証できるかを確かめます。最後に記録、人へ戻す条件と緊急停止を確認します。人が全部を読む状態から、機械と点検役が先に確かめる状態へ移します。付きっきりの指示は引き継ぎと見回りへ、口頭の注意は再発を防ぐ設定へ移します。知識もチャットから履歴付きの置き場所へ移します。手順を試す対象は、失敗の影響を限定できる業務から選びます。下表では、御社とARCHECOの担当を導入全体の段階に沿って確認できます。

何から始めるか：小さく試す対象と条件

ARCHECOは御社と、失敗の影響が小さく、完了条件が明確な作業を選びます。人が結果を確かめられることも条件です。テストの追加や文書更新から始められます。繰り返す修正や軽い作り直し、既存の型に沿う機能追加、コードレビューも候補です。既存の開発環境のまま、規約とテスト、権限と記録をAIが使える形にします。

ARCHECOの導入順は前節のとおりです。試す対象は、失敗の記録と重視する指標から決めます。以下は対象と施策を選ぶ際の参考です。日本HPは、過去1か月の失敗を10個書き出す一歩を勧めています。Algomaticは、まず保守性や速さ、要件を満たすことの優先順位を決めます。人の費用とシステムの費用も含めて考えます。Algomaticはその上で、原則→フック→スキル→検証の順に、AIの自由度を制限する施策から始めます。難しさと影響範囲を抑えるためです。ARCHECOも1つの業務と少数の失敗の型に絞ります。

小さく動かすと、不足する仕組みを観察できます。AI駆動開発協会は、AIを動かす周囲の仕組みを備えたOpenClawのような既製ハーネスを触り、記録を見ることを勧めています。＠ITが紹介するGoogleの動画で、ジェイコブソン氏は小さなハーネスを自作して原因を知る方法を勧めます。最初から全部の仕組みを入れず、今の構成で足りない部分を確かめます。

小さな失敗を、再発しない形へ変えるところまで試します。WEELの例では、0で割るときに決めたエラーを返すルールに、最初の実装が違反しました。テストで食い違いを見つけて直し、lessons.mdに教訓を残しています。やり直すと3件のテストが通りました。Googleの動画も、小さな変更から始めて長く安定すると確認してから範囲を広げます。言語の移行のような大きな仕事はその後です。

小さいチームでも、資料を整える担当は必要です。ファインディは人数より、資料整備に工数を割けるかを重視しています。使う範囲が限られ、整備の工数もない場合は向きません。一方、決まりをその場で直せる小さなチームなら、改善を早く反映できます。全社へ広げる前に、更新と評価を続けられるかを試します。続けられるかは、作成量だけでなく品質と人の負担も測って判断します。

ハーネスエンジニアリングの効果の測り方

ARCHECOは、AIの成果物の量と品質、人が確認・修正する負担を並べて測ります。量だけでは後始末の負担が見えないためです。AIsmileyもこの見方を勧めています。AI駆動開発協会は処理量・品質・人の負荷に、安全とハーネスの健全さを加えて整理しています。下表では、その指標と自社記録の例を分けました。

開発チーム全体の働き方も確かめます。AlgomaticはFour KeysとSPACEを併用しています。Four Keysはリリース頻度と変更から反映までの時間、変更の失敗率と復旧時間です。SPACEは、開発者の働き方を5つの観点で測る考え方です。満足と健康、成果、活動量に加え、やり取りと協力、効率と集中を見ます。開発だけが速くてもリリースが速くならず、人が疲れていれば続きません。

着手前に今の数字を取り、同じ業務と条件で比べます。ARCHECOが最初に見るのは、AIの停止回数と再開までの時間です。人の一押しを待った時間と、完了報告の差し戻し回数も測ります。導入そのものを目的にせず、どの待ち時間と手直しが減ったかを確かめます。

下表の記録は、それぞれ何を確認した数字かを区別して読みます。測定で分かった改善の効果と運用の負担を、次の費用の判断に使います。

費用を左右する対象・既存環境・承認・支援範囲

御社とARCHECOは、仕組みを作る作業量（工数）、運用支援、AI・道具の利用料を分けて見積もります。対象のAIと業務が増えるほど、接続と検証の範囲も広がります。既存のテスト・権限・記録が整っているかによって、最初に作る量が変わります。使えるAIやデータの置き場所、承認の重さも見積もりの条件です。

初期整備と維持のどちらに負担がかかるかは、現状によります。AIsmileyは維持の負担を重視し、ファインディは資料整理とAGENTS.md設計の初期工数を挙げています。出島の立ち上げ、人の配置、コーチングまで含める場合は、その範囲を別に合わせます。期間も同じ条件で変わります。部門をまたぐ承認と更新を含めれば、完成後も運用が続きます。

実行費用は、やり直しと検収の設計を含めて見ます。ARCHECOの見方では、やり直しが増えるほど利用料も増えます。検収を厳しくするとAIの実行費用が増え、人の手直しが減る可能性があります。

費用と品質、人の負荷を同じ作業で測り、釣り合いを決めます。

自社検証の実費は、御社の費用の目安ではありません。ARCHECOは、手元のMacで動くモデルと無料枠を使い、追加の支払いを抑えました。曲を28回作り直した分を含め、手元の電力の費用はかかっています。既存の環境を使った条件であり、支援の工数や御社の利用料の目安にはなりません。

依頼の型ごとのハーネスエンジニアリング費用

無料診断は依頼の入口で、後続の支援は「ハーネスを作る」「組織を整える」の2つです。無料診断では、概要から疑う原因と着手順を短く整理します。実装と検証、組織の整備や運用への伴走は、依頼する範囲に応じて費用を確認します。モデルと道具の利用料は支援の工数と別に確認します。範囲をそろえると、依頼先ごとの担当と成果物を比較できます。

ハーネスエンジニアリングを頼める相手の型

依頼先は、今の詰まりに合う支援の範囲で選びます。支援の型は、①研修、②道具の導入支援、③相談と実装支援、④設計・実装・運用の伴走です。御社が学びたいのか、作業を依頼したいのかで選びます。1社が複数の型を持つこともあります。相談の案内だけでは実装や運用まで含むかは分からないので、契約の前に作るものを確かめます。ARCHECOは、止まった場面の記録から欠けた仕組みを整理し、設計・実装した仕組みと運用の手順を引き継ぎます。契約前には、次の質問で、説明と実際の作業範囲が一致するかを確かめてください。

ハーネスエンジニアリングの依頼先に確かめる質問

御社の担当者は、依頼先へ作るものと検証方法を質問します。下の問いに、御社の業務を使って答えられるかを見てください。誰が承認し、誰が運用を引き受けるかまで合意してから着手します。回答を評価するときは、次の失敗を防ぐ運用まで含むかを見ます。

ハーネスエンジニアリングでよくある失敗

失敗を避けるには、仕組みを増やす量より、実際の詰まりに効いているかを見ます。作り込みすぎると、読む量が増えて重要な指示が埋もれ、反応も遅くなります。モデルの進化で不要な仕組みも出てきます。

ルールと既存コードは、放置せず点検します。古いルールはAIを誤った方向へ導き、悪い書き方は速く複製されます。検証を作らずに人のレビューへ任せれば、作る速さに確認が追いつきません。文章のお願いだけで済ませることや、承認をなくすことも失敗につながります。暗黙知を読む場所へ移す作業も必要です。

ARCHECOは、方針を書いたことと実行できることを分けて確かめます。ファインディも、AIの賢さを過大評価し、組織の未整備を小さく見る点を問題にしています。「待つな」「自分ごととして考えろ」と書くだけでは、判断は進みません。止まった場面で組織の基準に沿って選ぶ仕組みを作ります。「完成」を差し戻す検収と、事故からルールを直す運用も確かめます。ただし、仕組みを整えても、人が決めるべき事業上の判断や品質の基準は残ります。

ハーネスエンジニアリングの限界：仕組みでは決められないこと

ハーネスを作っても、AIの誤りはゼロになりません。誤りの確率と影響を抑え、早く見つけるための仕組みです。記録と戻し方を用意して検証した範囲で、すぐ戻せるようにします。何を作るか、どこまでの危険を許すかは人が決めます。譲れない品質や、割引率を30%にするか40%にするかという事業判断も残ります。人が明文化していない基準は判定できず、テストや型へ落とす必要があります。

個別に設計すべき問題も残ります。ファインディは、プロンプトインジェクションと複数AIの衝突を扱いきれていないと断っています。監査の厳しい業界や、古いコードの多い環境も同様です。Algomaticも、今の仕組みは開発とテストに集中し、要件定義・設計・運用への拡張は今後の課題としています。

運用を担う人の注意力にも限りがあります。Qiitaが紹介するRedditの個人投稿では、並行して見られる作業は3本程度とされています。一律の上限ではありませんが、確認できる量を計画に含めます。ハーネス自体を保守する担当がいなければ、導入しても形だけになります。

組織の基準は、AIに毎回読ませ、毎回確かめる必要があります。AIが会話を越えて組織の基準を使うには、基準を保存し、次の作業で読ませる仕組みが必要です。ARCHECOは、作った後に基準と仕組みを更新し続ける体制まで支援します。支援の説明が実際の運用に基づくかは、次の記録で、検証済みの範囲と残件を分けて確かめられます。

ハーネスエンジニアリングの自社検証：約10時間の開発と「完成」の裏側

ここに示すのは、ARCHECO自身の環境で行った自社検証です。2026年10月24日13時12分、代表がAIに一文を送りました。AIが作った曲だけを扱う音楽配信アプリを作り、店のBGMの有料配信を置き換えられるか、という依頼です。余力があれば短い動画アプリも作るよう添えました。画面設計も仕様書も技術選定も、人は行っていません。

人の指示は、判断を任せることと、方向や制約の修正が中心でした。「その都度あなたの判断で完全に決定して」と伝えています。途中で代表が、AIの作業を音楽配信アプリの構成を作るという意図へ戻させ、会議中に音が鳴った際には「止めて」と伝えました。夕方の「音を出さない」という決まりは、2時間後に「出してよい」へ変わりました。

約10時間後、AIは大手の音楽配信と同じ構成の主要画面・機能を実装していました。ホーム・検索・ライブラリの画面を備え、全画面プレイヤーで次の曲を並べ替えられます。プレイリストとオフライン再生もあり、店舗モードは時間帯でチャンネルを切り替えます。AIが作った曲は60曲・146分でした。保存52回、指示書22本、日誌547行の記録が残っています。

ARCHECOは、並行してAIに作らせた動画アプリの動作も確かめました。大手の短い動画アプリと同じ操作のアプリで、約14時間半で112機能中103が動きました。機能は本家の公式ヘルプから確認したものです。ライブ配信もブラウザ同士で数人まで動きました。残る9機能には、本当のお金のやり取りと外部の身元確認が必要でした。

一晩かけた8時間の連続再生テストでは、曲が205回切り替わり、停止もエラーも0でした。朝の時間帯へのチャンネル切り替えも挟んでいます。iPhone版の8時間の試験では196回切り替わり、停止0回でした。エラーと曲の重複が1回ずつ記録されましたが、AIの調査で、どちらも記録する側の誤検知と分かりました。

開発中の「完成」報告には、未実施の作業がありました。夜9時には曲を60曲そろえる作業と8時間の再生試験が後回しでした。Web点検の残りと、店で流す権利の確認も合わせて4つです。まとめ役のAIが報告を差し戻し、その夜に作業を進めさせています。「指示書7本とも1回で完了」という日誌の後にも、不具合は繰り返し出ました。

音源の品質には、未検証の範囲が残っています。機械の点検では60曲中54曲が要確認で、記事の記録時点では人の耳で1曲も聴いていません。基準に届かず生成し直した回数は28回でした。報告書にこの状態を明記させるにも、やり直しが要りました。ARCHECOは、権利の確認や人の試聴を、再生が止まらないことだけでは合格にしません。実費の条件は費用の節に分けて示しています。他社の実績も、同じように条件と未確認の範囲を分けて読みます。

公開されている他社の事例

公開事例は、条件と検証の範囲を合わせて読みます。OpenAIは2025年8月下旬に空のリポジトリから始め、約5か月で約100万行の製品を作りました。人が手で書いたコードはなく、社内の数百人と社外の試用者が使っています。当初3人で約1,500件を取り込み、1人1日平均3.5件でした。所要時間は手作業の約10分の1と推定されています。

OpenAIがAIに任せた範囲は、不具合の修正から変更の取り込みまでです。AIは1つの指示から不具合を再現し、修正後にアプリの動作を確かめます。変更の提出後はレビューに対応し、取り込みまで進めます。人の判断が必要な場合は、AIが人へ確認を戻します。OpenAI自身、この自律性は特定の構造と道具に依存すると断っています。ARCHECOも、同じ準備なしに数字を一般化しません。

異なる進め方や、効かなかった例も比較材料にします。Algomaticは複数案を並行開発し、テストの動画を課題管理の道具に添付しています。

電通総研の比較条件と数値は、前半の「同じモデルでも、ハーネスエンジニアリングで成績が変わる」の表にまとめています。点検役も一律に足さず、任せる作業で効果を確かめます。

個人の報告は、企業の検証と分けて読みます。Qiitaが紹介するRedditの投稿には、52日で約36万行を作った記録があります。第三者を介した個別例で、御社の効果を保証する数字ではありません。主な企業の報告は下表にまとめます。開発以外の業務に適用する場合も、正解をどう確かめるかが基準になります。

コーディング以外の業務への応用

御社の業務規程と正解の基準があれば、開発以外にもルール・検証・承認の仕組みを使えます。AIsmileyは下表の対応を示し、業務では結果を確かめて直す仕組みが手薄になりやすいと述べています。テストで正しさを確かめやすい開発に比べ、判定基準が書けない業務は難しくなります。経費精算や回答案の作成、社内文書や申請の確認が候補です。障害の検知と原因調査にも応用できます。

経費精算を例に、御社へ支援する方法を示します（支援の説明例）。

御社が用意する規程と正解の例：御社の業務担当者に、経費規程と小さな経費一覧をご用意いただきます。各支出を承認できるか、要確認とするかの正解と、根拠となる条文も決めていただきます。規程だけでは判断できない支出は、人に確認する対象として分けます。

ARCHECOが設定する制御：ARCHECOは規程をAIが読めるルールにし、参照する原本と判定結果の出力先を分けます。原本の書き換えを制限し、送信や重要データの更新は人の承認前に止めます。規程にない判断や実在しない条文を加えず、迷った点を残すように設定します。

合否の確認：御社の検収担当者が、AIの判定と根拠を用意した正解に照合します。「高すぎる気がする」といった理由を加えていないか、規程の空白を勝手に埋めていないかも確認します。ARCHECOは原本の保護と承認前の停止を検査します。原本は更新日時だけで判断せず、内容から計算する照合用の値（SHA256）を作業前後で比べます。

引き継ぐもの：ARCHECOは、規程を反映したルールファイルと権限・承認の設定を御社へ渡します。合否を確かめる基準・手順と検証記録も残します。規程が変わったときに更新する担当と再検査の手順を決め、御社で運用できる形にします。

参考として、Claude Worksは、架空の経費規程4条と経費一覧8件を使う練習問題を載せています。会議費には1人あたりの上限があり、タクシーには理由が必要です。領収書のない支出は不可で、電車とバスには経路を書きます。CLAUDE.mdの5行で始め、正解は、8件のうち4件を「要確認」と判定することです。高額な書籍は規程に上限がないため、問題なしとする点も確かめます。

向くかどうかは、手順と禁止事項が文書になっているかで判断します。結果を機械で判定でき、失敗の影響を戻せることも条件です。顧客への提案や文面の調子など、判定を書けない部分には承認を残します。その前後の作業からAIに任せます。ARCHECOの音源でも、権利や人の耳での品質確認が残ったことは同じです。御社の業務で判断できない部分があれば、無料診断で、必要な仕組みと人に残す確認を整理します。実務の説明はここまでです。続く参考では、関連用語・経緯・分類の違いを確認できます。

参考：3つの設計の範囲と関連用語

ここまでの実務説明を、他の解説と照合するための参考です。3つは入れ子として説明されますが、包含の向きには異説があります。一般的な説明では、ハーネスの設計に情報の渡し方が含まれ、その中に指示文の設計が含まれます。注目された時期は、指示文が2022〜2024年ごろ、情報の渡し方が2025年ごろです。周囲の仕組みの設計は2026年以降と整理されています。Qiitaは2025年にShopifyのTobi Lütke氏がコンテキストという言葉を勧め、Karpathy氏が賛同したと紹介しています。

既存の解説には、3つの範囲を対応づけた説明もあります。舞台では台詞・舞台装置・劇場全体、仕事では依頼メール・添付資料・オフィスの順です。Qiitaは、報告書の書き方・会議資料の準備・プロジェクト全体の運営体制という対応も示します。狭い定義ではハーネスを事前に進め方を示す指針と、実行結果を検査する仕組みに限り、コンテキストの内側に置きます。手順書やスキルも、ビジネス+ITはコンテキスト側、WEELとAIsmileyはハーネス側に置きます。社内で使う範囲を先に合わせてください。

関連する用語も、何をする仕組みかで区別します。ガードレールは、入力・出力・道具の操作を検査し、危険な処理を止めるハーネスの一部です。kinopee氏は「ハーネスは主観、ガードレールは客観」と対比しています。主観は事前に進め方を示す設計、客観は実行結果を外から判定する検査という対比です。機械で判定できる範囲が広がれば、任せる範囲も広がります。評価ハーネスはモデルの採点用です。ループエンジニアリングは、AIが試し、結果を確かめて直す繰り返しを設計することです。安定して繰り返すには、情報の保存や操作を制御するハーネスが必要です。Geoffrey Huntley氏が広めたRalph Wiggum Loopも、AIに同じ指示を渡して再実行させる手法です。

フレームワークは組み立てる部品集、ランタイムは実行基盤、SDKは開発用の部品一式です。一創はハーネスを、それらが組み上がり既定値も決まった実行体と区別します。Human-in-the-Loopは、決めた場面で人が確認や承認する仕組みです。Software Design誌は、Karpathy氏が2025年2月にVibe Codingを提唱したと紹介しています。Vibe Codingは、人がコードを読まずにAIの成果物を受け入れる進め方です。Agentic CodingはAIに自律的に作業させ、機械の検査と最後の受け入れで品質を確かめる開発です。仕様駆動開発は、先に仕様書を書き、ルールと完了の定義を厚くする進め方です。

参考：ハーネスエンジニアリングという言葉の経緯

ハーネスエンジニアリングという言葉は、以前からあった実装を説明する名前として広がりました。起点や定義は媒体によって異なるため、唯一の発明者は決めません。この名前が広まる前から、AIへのルールを書く .cursorrules などを使う現場があり、kinopee氏は「実装が先、命名は後」と整理しています。半年ほどで設計の分野として語られるようになった経緯は下の年表に示します。

定義の違いは、依頼する範囲を決めるときに確かめます。kinopee氏が整理した5つの流派では、Harrison Chase氏はモデル以外の全部、Mitchell Hashimoto氏は失敗ごとの環境改善を重視します。Martin Fowler氏のサイトのBirgitta Böckeler氏（Thoughtworks）は事前に進め方を示す指針と、実行結果を検査する仕組みに限ります。Avi Chawla氏は入れ子で説明し、OpenAIのCodexチームは大規模開発の実践から語ります。ハーネスをOSにたとえ、モデルや道具を動かす環境として説明する見方もあります。

足場（scaffold）も用法が揺れます。電通総研は、実行前の設定を足場、実行中の仕組みを狭い意味のハーネスと呼び分けます。ファインディとAIsmileyによれば、Anthropicは両者を同義で使います。このページでは7つの仕組みをハーネスとし、組織の5つの備えを分けます。次の対応表では、各解説の分類を、このページの7つの仕組みと照合できます。

参考：他の分類と7つの仕組みの対応

分類の数は統一されておらず、同じ部品を違う粒度でまとめています。CodeZineの解説でも、部品は独立して追加・削除でき、実行する順番も変えられます。NTTデータの「運用」は統制・説明責任・監査・変更管理で、組織の備えとして扱います。下表の番号は、前半の7つの仕組みに対応します。人の担当や承認手続きは、前半の「組織の5つの備え」にまとめています。関連する背景は続く記事、導入前の疑問はFAQで確認できます。