A&A INSIGHTS
顧客データをどこまでAIに渡すか：受託で決める入力範囲と、契約に書く責任
受託でAIに渡す顧客データは、常時渡す・必要なときだけ参照する・渡さないの三つに分けて着手前に合意します。関係のない情報を減らすことは精度の要件でもあり、預かる範囲はアクセス権限を外して初めて狭まります。
Read in English
この記事の要点
顧客から預かったデータは、常時モデルへ渡すもの・必要なときだけ参照するもの・渡さないものの三つに分け、着手前に合意します。「念のため全部渡す」は安全側の選択ではありません——判断に関係のない情報を減らすことは精度の要件でもあり、預かる範囲のほうは、モデルへ入れないと決めるだけでは狭まらず、アクセス権限を外して初めて狭まるからです。
答え：顧客データは「常時渡す・必要時に参照する・渡さない」の三つに分ける
A&Aの考え方
顧客から共有フォルダごとデータを渡されたとき、最初に決めるのは「どのモデルを使うか」ではありません。データを三つの区画に分けることです。第一に、常時モデルへ渡すもの——その業務の判断に毎回必要で、量が限られている情報。第二に、必要なときだけ参照するもの——保存場所と探し方だけを手元に持ち、処理の途中で必要になった分を取りに行く情報。第三に、渡さないもの——この案件の判断には使わないと決め、モデルへは入れない情報。この三分割を着手前に文章にし、顧客の合意を取ります。「渡さない」と決めたデータについては、同じ場でアクセスの扱いも決めます——受け取らない、権限を外してもらう、どうしても外せないなら理由といつまで残るかを書く。モデルへ入れないことと、預かっていないことは別だからです。あわせて、第三者のサービスを経由する部分について、その事業者と契約するのは誰か、どのデータがいつどこを通ったかをどこに記録するかを決めます。
A&Aの考え方
「念のため全部渡す」が安全側に見えるのは、足りないより多いほうが事故が起きにくいという直感が働くからです。しかし受託では逆向きに効きます。ここで一つ区別が要ります。預かった範囲を決めるのは、モデルへ渡した量ではなく、顧客がアクセスを許した範囲です。共有ドライブごと権限をもらった時点で、漏れたときに説明する責任の範囲も、案件終了後に削除を確認する対象も、そのドライブ全体に広がっています。モデルへ入れないと決めるだけでは、この範囲は狭まりません。狭めるには、受け取らないか、権限を外してもらう必要があります。見積もりには入れていないのに、負う責任だけが増えるのはそのためです。
A&Aの考え方
そしてもう一つ、技術側の理由があります。渡す情報を増やせば精度が上がるとは限りません。文脈の量とモデルの判断の正確さは、単純な比例関係ではないからです。この点は後の節で出典に沿って確認します。先に結論を言えば、データを絞る作業は、法務のための我慢ではなく、精度を出すための設計と同じ向きを向いています。だから二つの話を一つの判断としてまとめられます。ただし、この二つを一つにまとめること自体はA&Aの整理であり、出典が述べている主張ではありません。
Anthropic：文脈は「逓減する限界収益を持つ有限の資源」である
出典に基づく事実
Anthropicが2025年9月29日に公開した文脈設計の解説は、トークン数が増えるほどモデルがその文脈から情報を正確に思い出す能力が落ちるという「context rot」を挙げ、劣化のしかたには差があるものの「この性質はすべてのモデルに現れる（this characteristic emerges across all models）」としています。そのうえで「文脈は、したがって、逓減する限界収益を持つ有限の資源として扱われなければならない（Context, therefore, must be treated as a finite resource with diminishing marginal returns）」と述べています。
出典に基づく事実
同じ解説は、良い文脈設計とは「望む結果の確率を最大化する、可能な限り小さい高信号トークンの集合を見つけること（finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome）」だと定義しています。
出典に基づく事実
理由として同解説は、LLMには大量の文脈を読むときに使う「注意の予算（attention budget）」があり、新しいトークンはそれをいくらか消費すると説明しています。またトランスフォーマー構造ではn個のトークンに対して対になる関係がn²生じるため、文脈が長くなるほどその関係を捉える力が薄く広がり、文脈の大きさと注意の集中のあいだに自然な緊張が生まれるとしています。同解説はこれを断崖ではなく「性能の勾配（a performance gradient rather than a hard cliff）」と呼び、長い文脈でもモデルは高い能力を保つが、情報の取り出しと長距離の推論の精度は短い文脈のときより落ちうるとしています。
A&Aの考え方
受託の設計に置き換えると、共有フォルダを丸ごと投入する方式は「多めに入れておけば判断材料が増える」ではなく、「判断に関係のない情報で注意の予算を使う」方式にあたります。ここで注意すべきは、出典が述べているのはモデルの性能についてであり、機密保持や法的責任については何も述べていないという点です。この節から持ち出せるのは、渡す量を絞ることに精度側の理由があるという一点だけです。
| データの区画 | モデルへの渡し方 | 着手前に決めること |
|---|---|---|
| 常時渡す（判断に毎回必要で量が限られる） | 文脈へ入れておく | 顧客が合意した利用範囲と、列の単位での対象 |
| 必要なときだけ参照する（量が多く一件には一部しか要らない） | 保存場所と探し方だけ持ち、実行時に取りに行く | 顧客側に参照権限と、誰が何をいつ見たかの記録があるか |
| 渡さない（この案件の判断には使わないと決めた） | 入れない | 使わないと決めた理由と、アクセスを外すか残すか（残すなら期限） |
| 判断保留（区画がまだ決まっていない） | 決まるまで渡さない扱い | いつ誰と決めるか、決まるまで権限を外してもらうか |
| 第三者を経由する部分 | 経由先を一覧にする | 事業者との契約者、記録の置き場所、終了後の扱い |
全部を先に処理せず、識別子だけ持って必要なときに読む
出典に基づく事実
同じ解説は、関連しそうなデータを事前に全部処理する方式に対して、「just in time（必要なときに）」の文脈戦略を説明しています。この方式のエージェントは「軽量な識別子（ファイルパス、保存済みクエリ、ウェブリンクなど）を保持し（maintain lightweight identifiers (file paths, stored queries, web links, etc.)）」、その参照を使って実行時に道具経由で必要な分だけ文脈へ読み込みます。
出典に基づく事実
例として、Anthropic自身のコーディング用エージェントが大きなデータベースに対する複雑な分析を行う際、対象を絞ったクエリを書き、結果を保存し、headやtailのようなコマンドを使うことで、データ全体を文脈へ読み込まずに大量のデータを扱うと説明されています。同解説はこのやり方を、人が全部を記憶するのではなくファイルシステムや受信箱、ブックマークのような外部の整理と索引を用意して必要なときに取り出す認知のしかたに重ねています。
出典に基づく事実
同解説は、エージェントが自分で辿って取りに行く方式には「漸進的な開示（progressive disclosure）」という利点もあるとしています。やり取りごとに次の判断の材料が得られ、ファイルの大きさが複雑さを示し、命名規則が用途を示し、更新時刻が関連度の代わりになる、という説明です。これにより、網羅的だが無関係かもしれない情報に溺れるのではなく、関連する部分集合に集中した状態を保てるとしています。
A&Aの考え方
受託の設計で使えるのは、「参照できる状態にしてある」ことと「渡してある」ことは別だという点です。顧客のデータを必要なときに取りに行ける状態にしておけば、常時モデルへ入れておく必要はありません。この区別が、三分割の真ん中——必要なときだけ参照する区画——の中身になります。なお出典はこれを精度と効率の問題として書いており、預かる責任の問題として書いてはいません。責任の側の理由は、次の節の別の出典から来ます。
NIST AI RMF：第三者のデータと資源は、手順があり、従われ、記録されている状態にする
出典に基づく事実
NISTのAI Risk Management Framework 1.0（2023年）のCoreは、MAP機能のMap 4として「第三者のソフトウェアとデータを含め、AIシステムのすべての構成要素についてリスクと便益が対応付けられる」ことを掲げています。その下のMap 4.1は、構成要素の技術的・法的リスクを対応付ける手法が——「第三者のデータまたはソフトウェアの利用を含めて（including the use of third-party data or software）」——「整備され、従われ、文書化されている（are in place, followed, and documented）」ことを求め、第三者の知的財産その他の権利を侵害するリスクも対象に含めています。
出典に基づく事実
同じCoreのMANAGE機能では、Manage 3が第三者に由来するリスクと便益の管理を掲げ、Manage 3.1が「第三者資源に由来するAIのリスクと便益が定期的に監視され（AI risks and benefits from third-party resources are regularly monitored）、リスク管理策が適用され文書化されている」ことを求めています。
出典に基づく事実
Map 1.1は、意図した目的、有益になりうる用途、「文脈に固有の法・規範・期待（context-specific laws, norms and expectations）」、そしてシステムが置かれる想定環境が理解され文書化されていることを求めています。考慮事項として、利用者の種類とその期待、個人・地域社会・組織・社会・地球への正負の影響、そして目的・用途・リスクについての前提と関連する限界などが挙げられています。
A&Aの考え方
受託側が読み取れるのは、求められているのが「安全なモデルを選ぶこと」ではないという点です。第三者を経由する部分について手順があり、それに従っており、記録が残っている——その状態が求められています。つまり成果物の品質とは別に、どのデータがどの第三者を通ったかを後から説明できる形が必要になります。さらに「定期的に監視」と明記されていることは、決めた時点で終わりではなく、運用している期間ずっと責任が続くことを示します。案件の見積もりでは、ここが保守の側に落ちやすい部分です。
法務の話と精度の話を、一つの設計判断にまとめる
A&Aの考え方
ここまでの二つの出典は、別のことを述べています。文脈設計の解説はモデルの精度について書き、NISTのCoreは第三者を経由するリスクの文書化について書いています。どちらも「顧客データを絞れ」とは述べていません。この先はA&Aの整理です。
A&Aの考え方
整理はこうです。渡す量を減らすと精度が上がるという因果と、預かる範囲を狭めると責任が減るという因果は、別のものです。前者は条件付きで、判断に関係のない情報を減らしたときにだけ成り立ちます。関係のある情報まで削れば精度は落ちます。後者は、預かった範囲が説明責任と削除確認の範囲になるという受託の構造から来ます。別の作業ですが、決まるのは同じ一枚の表の上です。どのデータを使わないと決めるかが、どの権限を外せるかを特定するからです。だから二回に分けて考える必要はありません。
A&Aの考え方
この整理が実際に効くのは、社内で判断が割れる場面です。技術側は「文脈を増やせば精度が上がる」と考え、管理側は「渡す範囲を減らせ」と言う。二つが対立しているように見えると、結論は「とりあえず全部渡して、後で考える」に落ちます。判断に関係のない情報を減らすことが精度の側にも有利だと分かれば、これは対立ではなく同じ作業になります。
A&Aの考え方
ただし逆向きの誤解も避ける必要があります。「絞れば絞るほどよい」ではありません。出典自身が、要約や圧縮をしすぎると「微妙だが決定的な文脈の喪失（the loss of subtle but critical context）——その重要さは後になって初めて明らかになる」が起きうると述べています。三分割の目的は量の最小化ではありません。どのデータがどの区画に属するかを事前に決め、記録しておくことです。
三つの区画の定義と、四つ目の行
A&Aの考え方
常時渡す区画に入れてよいのは、その業務の判断に毎回必要で、量が限られ、個人を特定する情報を含まないか、含むとしても顧客がその範囲での利用に合意している情報です。社内の用語集、過去の判断の要約、対象になる商品の一覧のように、変わりにくく小さいものが典型です。ここに「念のため」を入れないことが、この区画の設計です。
A&Aの考え方
必要なときだけ参照する区画は、保存場所と探し方だけを手元に持ち、処理の途中で必要になった分を取りに行くデータです。顧客の業務記録、取引の明細、過去の問い合わせ本文のように、量が多く、一件の判断にはそのうちごく一部しか要らないものが入ります。ここに置けるかどうかは、顧客側に参照の権限管理と、誰が何をいつ見たかの記録があるかで決まります。無い場合の扱いは後の節で述べます。
A&Aの考え方
渡さない区画は、この案件の判断には使わないと決めたデータです。使えないデータではなく、使わないと決めたデータであるという点が重要です。決めた理由を一行書いておくと、後から「なぜこの精度なのか」と問われたときに、範囲外にしたからだと答えられます。理由を書かずに外すと、同じ問いが設計の失敗として戻ってきます。そして同じ行で、アクセスの扱いも決めます。受け取らない、権限を外してもらう、どうしても外せないなら理由と期限を書く。モデルへ入れないことは入力の設計、預かる範囲を狭めることは権限の設計で、二つは別の作業です。
A&Aの考え方
三つのうち省略されやすいのは三番目だと見ています。これは当社が数えた結果ではなく、範囲の決め方についての編集上の見方です。常時渡すものと必要時に参照するものだけを決め、残りを「とりあえず共有フォルダに置いたまま」にすると、区画は実質二つになります。預かってはいるが使い道が決まっていないデータが残り、責任だけが増えます。渡さないと決めることは消極的な選択ではありませんが、それ自体で範囲が閉じるわけでもありません。閉じるのは権限を外したときで、「渡さない」の決定はそのための前提です。
A&Aの考え方
分類の判断がつかないデータは、四つ目の行として「判断保留」で明記します。保留のまま常時渡す側へ流れ込むのを防ぐためで、保留のものは渡さない扱いにしておき、必要になった時点で顧客と決めます。保留の行には、いつ誰と決めるかも書いておきます。書かないと保留は消えず、案件の終わりまで残ります。
データの種類ごとに埋める六つの欄
A&Aの考え方
区画を決めたら、データの種類ごとに六つの欄を埋めます。欄が多いほど良いわけではありません。この六つは、埋まらないうちは着手できない項目として選んだものです。
A&Aの考え方
第一欄は区画とその理由です。常時渡す・必要時参照・渡さない・判断保留のどれかと、なぜそこに置いたかを一行。第二欄はアクセスの扱いで、受け取らない・権限を外してもらう・残す（理由と期限つき）のどれかを書きます。この欄が、預かる範囲を実際に狭める唯一の欄です。第三欄は、経由する第三者サービスの名前と、その事業者と契約するのは受託側か顧客かです。ここを決めずに受託側のアカウントで動かすと、顧客のデータが受託側の契約条件の下を通ることになります。多くの場合それは意図した設計ではありません。
A&Aの考え方
第四欄は、顧客側で必要な権限整備です。必要時参照のための参照権限と監査の記録があるか、無いなら誰がいつ作るか。第五欄は記録の置き場所——どのデータがいつどの第三者を通ったかを、どこにどの粒度で残すか。第六欄は案件終了後の扱いで、削除するのか顧客へ返すのか、残すならどこにどの期間かを書きます。受託側で作った抽出や索引も、この欄の対象です。
A&Aの考え方
この六つのうち、受託側だけで埋められるのは第一欄と第五欄です。第二欄・第三欄・第四欄・第六欄は顧客の判断が要ります。だからこの表は、着手前の打ち合わせに持ち込む資料として作ります。着手後に埋めようとすると、第四欄が空のまま実装が進み、権限が降りてこないという待ちが発生します。
出典に基づく事実
第三欄と第五欄は、NIST AI RMF Coreが第三者のデータまたはソフトウェアの利用を含めた手法について「整備され、従われ、文書化されている」ことを求め、さらに第三者資源に由来するリスクと便益が「定期的に監視され、リスク管理策が適用され文書化されている」ことを求めている箇所に対応します。ただしCoreが並べているのは達成すべき結果であって、文書の様式ではありません。同じページは、各組織が自らの文脈で適用できる戦術的な提案を示す補助資料としてPlaybookが別にあるとも記しています。六つの欄の設計はA&Aのものです。
この分け方が見積もりに足す三つのもの
出典に基づく事実
出典は、必要なときに取りに行く方式の代償を明記しています。「もちろん、代償がある。実行時の探索は、事前に計算したデータを取り出すより遅い（Of course, there's a trade-off: runtime exploration is slower than retrieving pre-computed data）」。さらに、意図のある丁寧な設計がなければ、エージェントは道具を誤用し、行き止まりを追い、重要な情報を見つけられずに文脈を無駄にしうるとしています。
A&Aの考え方
したがって見積もりで増えるのは、モデルへの接続作業ではありません。増えるのは三つです。顧客側のアクセスを整える作業——必要時参照のために与える権限と、渡さないと決めた分の権限を外してもらう依頼の両方を含みます。どのデータがどこを通ったかを残す仕組み。そして、遅くなる分を許容できる業務かどうかの確認です。三つ目は作業量ではなく要件の確認ですが、ここを飛ばすと実装後に設計をやり直すことになります。
A&Aの考え方
このうち顧客側の権限整備は、受託側だけでは終えられません。顧客の情報システム担当か、それを兼任している人の時間が必要です。だからここは「うちの作業」に混ぜず、別見積もりの作業として切り出します。切り出さないと、着手後に待ちが発生し、その待ちの理由が受託側の遅れとして見えます。別見積もりにしておけば、遅れの所在が最初から共有されます。
A&Aの考え方
遅くなる分の確認は、業務の性質によります。問い合わせへの一次返信のように秒単位の応答が要るものと、月次の照合のように分単位で構わないものでは、必要時参照に回せる範囲が変わります。三分割は固定の正解ではなく、応答時間の要件と一緒に決めるものです。応答時間が厳しい業務では、常時渡す区画を小さく作り直すほうが、必要時参照を増やすより現実的なことがあります。
一枚の表に起こしてみる：小売チェーンの問い合わせ一次対応（架空の例）
仮想例
以下は架空の例です。A&Aの実績ではなく、三分割の使い方を具体的に示すために作った設定です。十店舗の小売事業者から、各店舗に届く問い合わせメールの一次整理——分類と、過去に同じ案件があるかの確認——を請けるとします。顧客は共有ドライブのアクセス権をまとめて渡してきました。中身は、商品マスタ、在庫の日次ファイル、過去三年分の問い合わせメール、従業員の名簿、店舗別の売上明細です。
仮想例
常時渡す区画に入れるのは、商品マスタのうち名称・型番・保証期間の列、店舗の所在地と営業時間、そして問い合わせの分類一覧です。小さく、変わりにくく、個人を特定しません。商品マスタの全列ではなく三列だけにする点が、この区画の作り方です。
仮想例
必要なときだけ参照する区画に入れるのは、過去三年分の問い合わせメール本文です。一件の一次整理に必要なのは、同じ型番についての過去のやり取りが数件あるかどうかだけで、三年分を常時文脈へ入れる理由がありません。保存場所と検索の条件だけを持ち、該当する数件を実行時に取りに行きます。
仮想例
渡さない区画に入れるのは、従業員の名簿と店舗別の売上明細です。一次整理の判断には使いません。理由としてそれぞれ一行、「分類と過去照合に不要」と書いておきます。あわせてアクセスの欄に、この二つのフォルダは閲覧権限を外してもらうと書き、実際に外してもらいます。モデルへ入れないだけでは、共有ドライブごと預かったままだからです。判断保留にするのは在庫の日次ファイルです。在庫の有無を一次返信に含めるかが未決のためで、決まるまでは渡さない扱いにし、在庫フォルダの権限も一度外してもらったうえで、誰といつ決めるかを行に書いておきます。
仮想例
第三者の欄には、経由するモデル提供事業者を一社書きます。契約者を受託側にするか顧客にするかをここで決めます。記録の欄には、どの問い合わせでどの過去メールを参照したかを一行ずつ残すと書きます。終了後の欄には、参照用の索引は削除し、常時渡す側に作った三列の抽出は顧客へ返すと書きます。
A&Aの考え方
この例で見積もりの外にあったのは、在庫ファイルの保留を解くための顧客側の確認、過去メールへの参照権限をどのアカウントに与えるかの決定、そして名簿と売上明細の権限を外す作業でした。いずれも受託側では決められません。表を着手前に出していれば三つの依頼としてまとめて渡せますが、着手後に気づけば、実装が止まっている理由の説明から始めることになります。
この分け方が合わない条件と、主張しないこと
A&Aの考え方
この分け方が要らない、あるいは合わない条件があります。まず、顧客のデータをまったく預からず、処理が顧客の環境の中だけで完結する案件では、第三欄以降はほとんど埋まりません。その場合に三分割を形だけ作る意味はありません。
出典に基づく事実
出典自身も、常に必要時参照にすべきだとは述べていません。「ある状況では、最も効果的なエージェントは混成の戦略を使うかもしれない。速度のために一部のデータを事前に取得し、残りは自らの裁量でさらに自律的な探索を進める（In certain settings, the most effective agents might employ a hybrid strategy, retrieving some data up front for speed, and pursuing further autonomous exploration at its discretion）」としており、どの程度の自律性が正しいかは作業内容によるとしています。同解説は、この混成が「法務や財務の仕事のように、内容の動きが少ない文脈」に向きうるとも書いています。
A&Aの考え方
むしろ問題になりやすいのは逆の場合だと見ています（これも編集上の見方で、当社の集計ではありません）。顧客側に参照の権限管理も監査の記録も無いとき、必要時参照へ寄せると、受託側が代わりに権限の仕組みを作ることになり、複雑さが増えます。その場合の代替は、必要時参照の区画を一度空にし、常時渡す区画を「その業務に必要な最小の列だけを抜き出した複製」として作ることです。複製を作る手間と、複製が古くなることの管理が増えます。さらに、その複製自体が受託側の預かる範囲に入ります——どこに置き、いつ消すかを終了後の欄に必ず書いてください。それでも、顧客側の整備を待たずに着手できます。この代替を選んだこと、選んだ理由、複製をいつ作り直すかを記録に残します。
出典に基づく事実
NIST AI RMFは任意適用の枠組みです。同じ資料のページは、付属のPlaybookについて「AI RMFと同様に、Playbookは任意であり（Like the AI RMF, the Playbook is voluntary）」組織は自らの必要と関心に応じて提案を利用できると記しています。あわせて同じページの冒頭には「AI RMF 1.0 は更新中である。改訂版を作成中（The AI RMF 1.0 is being updated. A revised version is in progress.）」と掲示されており、本記事が引用しているのは2023年版1.0からの抜粋です。
A&Aの考え方
主張しないことを明記します。本記事は日本の個人情報保護法その他の法令への適合を判断するものではありません。第三者提供や委託の該当性といった解釈は、読者が自身の顧問に確認する事項です。NIST Coreに沿った記録があることは、法令適合の証明にはなりません。また「渡す量を減らすと精度が上がる」は、判断に関係のない情報を減らした場合に限られる条件付きの主張です。関係のある情報まで削れば精度は落ちます。A&Aの顧客での実施結果、削減率、精度の改善幅は示していません。本記事の三分割と六つの欄はA&Aの設計案であり、出典が示す様式ではありません。
次の一歩：いま迷っている一件で、「渡さない」の行だけ先に書く
A&Aの考え方
いま判断に迷っている案件があるなら、三つの区画を全部埋めようとせず、「渡さない」の行だけを先に書いてください。預かっているデータの一覧を出し、この案件の判断には使わないものに印を付け、理由を一行添える。ここまでなら顧客との合意も要らず、一覧の長さにもよりますが短い時間で終わります。それだけで、預かる範囲がどこまで広がっていたかが見えます。そのうえで、印を付けた行のうち権限を外せるものを顧客に依頼すれば、範囲が実際に狭まります。
A&Aの考え方
そのうえで残ったものについて、常時渡すか必要時に参照するかを決めます。判断がつかない行が残ったら、保留として渡さない扱いにし、顧客と決める会議の議題にします。入力の範囲と書き込みの範囲は別の判断軸です。入力の範囲は「使わないと決められるか」で決まり、書き込みの範囲は「失敗したとき誰が原状回復するか」で決まります。同じ案件で両方を決める必要があっても、同じ基準では決められません。
A&Aの考え方
書き込みの側の線引きは「顧客システムへの書き込みまで請けるか：最初のAI納品で引く線」で扱っています。顧客獲得から継続までの全体像は「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」にあります。対象の業務がすでに決まっていて実装の範囲を固めたい段階であれば、開発の相談が適切です。どの業務を対象にするかがまだ決まっていなければ、先にそこを決める段階で、入力範囲の表はその後になります。
顧客データの範囲は、着手してから相談することではなく、着手前に三つに分けて合意することです。常時渡す・必要なときだけ参照する・渡さないの三分割に判断保留の行を加え、各行でアクセスを外すかどうかを決め、第三者を経由する部分の契約者と記録の置き場所を決める。渡す量を絞る理由は機密保持だけではありません。判断に関係のない情報を減らすことは精度の要件でもあります。だから「念のため全部渡す」は、責任と品質の両方で不利な選択です。なお責任の側が実際に軽くなるのは、モデルへ入れないと決めた時点ではなく、その権限を外した時点です。ただし絞ることの代償——必要時参照は事前取得より遅く、顧客側の権限整備を前提にする——も、同じ表の上で見積もってください。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Effective context engineering for AI agents
Anthropic · 2025-09-29
確認日 2026-10-03 - AI RMF Core
NIST AI Resource Center · excerpt from NIST AI RMF 1.0 (2023); page shows no separate date
確認日 2026-10-03
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-10-03