A&A INSIGHTS
顧客システムへの書き込みまで請けるか：最初のAI納品で引く線
顧客から「登録まで自動で」と言われ、最初の契約に書き込み権限を含めるか迷っている受託事業者へ。Anthropicのツール設計とChatbase事例をもとに、書き込みを可逆・補償・不可逆に分けて範囲と見積もりを決める手順をA&Aが整理します。
Read in English
この記事の要点
最初の納品に含めてよい書き込みは、対象システムに取り消しの手順があり、その取り消しを受託側が自分で実行できるものまでです。打ち消す別の操作が必要な書き込みと、外に出たら戻せない書き込みは別見積もりにします。読み取りと書き込みの差は接続の難しさではなく、失敗したとき誰が原状回復するかです。
答え：最初の納品は「自分で取り消せる書き込み」までにする
A&Aの考え方
最初の納品に含めてよい書き込みは、対象システムに取り消しの手順があり、その取り消しを受託側が自分で実行できるものまでです。取り消しがきかず別の操作で打ち消すしかない書き込みと、外に出たら戻せない書き込みは、最初の契約には入れず別見積もりにします。顧客から「どうせなら登録まで自動で」と言われたとき、答えるべきは「できます／できません」ではなく、「この操作は失敗したとき誰が戻しますか」です。
A&Aの考え方
読み取りと書き込みは、接続作業としては同じ工程に見えます。認証情報を受け取り、項目を対応づけ、エラーを処理する。難しさの差はそこにはありません。差が出るのは失敗したあとです。読み取りが間に合わなければ、提案が出てこないだけで、顧客のデータは元のままです。書き込みが間に合わなければ、顧客のシステムの中身が変わっています。そして「元に戻す」という作業の担当者は、契約に書いていなければ決まっていません。
A&Aの考え方
この記事では、出典に書かれている技術的な記述、A&Aによる受託の範囲決めへの読み替え、架空の記入例を分けて示します。出典はいずれもAnthropicが公開したエンジニアリング解説と顧客事例であり、日本の受託契約における条項の有効性や、読者の監査・内部統制の要件への適合を判断するものではありません。契約文面はご自身の顧問にご確認ください。
Anthropic：作らない道具を選ぶこと、そして「破壊的な変更」を申告すること
出典に基づく事実
Anthropicが2025年9月11日に公開したツール設計の解説は、高品質なツールを書くための原則の一番目に「実装する道具、そして実装しない道具を選ぶこと」（Choosing the right tools to implement (and not to implement)）を挙げています。同解説はさらに、よく観察される誤りとして「既存のソフトウェアの機能やAPIのエンドポイントを単に包んだだけの道具」（tools that merely wrap existing software functionality or API endpoints）を名指ししています。
出典に基づく事実
同解説は具体的な置き換え例も示しています。すべての連絡先を返すlist_contactsではなくsearch_contactsやmessage_contactを作る。ログをまるごと返すread_logsではなく、関係する行とその周辺だけを返すsearch_logsを作る。そして「作る道具のそれぞれに、明確で固有の目的を持たせること」（Make sure each tool you build has a clear, distinct purpose）と述べ、何を作り何を作らないかを慎重に選ぶことは本当に効果があるとしています。
出典に基づく事実
同解説の末尾近くには、範囲決めに直接使える記述があります。MCPサーバー向けに道具を書く場合、ツール注釈（tool annotations）は「どの道具が開かれた世界への接続を必要とするか、あるいは破壊的な変更を行うかを申告する助けになる」（help disclose which tools require open-world access or make destructive changes）というものです。つまり道具の一覧の中で、戻せない変更を起こす道具は、他と区別して申告されるべきものとして扱われています。
A&Aの考え方
A&Aがここから借りるのは、見積もりの立て方そのものです。この解説は「全部のAPIに対応する」ことを良い設計とは呼んでいません。むしろ、作らない判断を最初の原則に置き、戻せない変更を起こす道具には申告という扱いを与えています。受託の範囲決めに読み替えるなら、顧客のシステムにあるAPIの一覧を工数の一覧として扱うのをやめ、破壊的な変更を起こす操作だけを抜き出して別の欄に置く、ということになります。ただし出典はソフトウェア設計の原則を述べているだけで、契約や責任分担については何も述べていません。この読み替えはA&Aの設計です。
| 書き込みの種類 | 最初の納品に含めるか | 含めるために先に決めること |
|---|---|---|
| 読み取りと提案のみ | 標準の範囲 | 提案の根拠レコード、参照時点、参照できなかった項目を提案に添える |
| 可逆（取り消し手順があり受託側で実行できる） | 含めてよい | 取り消しの手順と、戻したことを誰にいつ知らせるか |
| 補償が必要（取り消せないが打ち消す操作がある） | 条件付きで別見積もり | 打ち消す操作の実行者と、その実行に顧客の承認が要るか |
| 不可逆（外に出たあとは戻せない） | 最初は含めない | 実行前の確認者、その人が見る材料、確認が遅れたときの扱い |
| 対象外として列挙するもの | 範囲外 | 分類の判断がつかない書き込みを、曖昧なまま含めずに明記する |
Chatbase：請求書の確認と返金の処理が、同じ連携のなかに並んでいる
出典に基づく事実
AnthropicのChatbase事例ページは、同社のプラットフォームが「APIを通じて業務システムと連携し、AIエージェントが直接の行動を取れるようにしている」（integrating with business systems through APIs, enabling AI agents to take direct actions）と述べています。そしてStripe連携の例として、「エージェントは請求書の確認や返金の処理といった作業を扱える」（agents can handle tasks like checking invoices and processing refunds）とし、そこに「機微な操作については任意で人の監督を付けて」（with optional human oversight for sensitive operations）という条件を添えています。
出典に基づく事実
同じページの前半では、この構成を「Stripeでの注文状況の確認から、人の監督付きでの返金処理まで」（from checking order status in Stripe to processing refunds with human oversight）と書き分けています。また同社は人を介在させる仕組みを整えつつあり、「簡単な一回のクリックによる確認を通じて効率的な監督を可能にする」（efficient oversight through simple one-click confirmations）ことを進めているとされています。
A&Aの考え方
この一文に、読み取りと書き込みが並んで入っていることがA&Aには重要です。注文状況の確認も返金の処理も、同じStripe連携のなかの作業として書かれています。接続としては同じです。にもかかわらず、人の監督という語が付いているのは返金の側だけです。しかも監督は「任意」とされています。確認の有無が操作ごとに分かれていて、その分岐が設計の対象になっている、という構造がここに現れています。
A&Aの考え方
同時に、この記述が何を言っていないかも押さえておきます。どの操作を「機微」と呼ぶかの基準は、このページには書かれていません。監督を付けた結果として誤りが実際に止まったかどうかも書かれていません。確認のクリックが一回で済むという記述は、確認する人が判断に必要な材料を受け取っているかどうかとは別の話です。これはAnthropicが公開したベンダー側の記述であり、独立した監査ではありません。同ページの利用者数に関する数値は、母集団や期間の定義が示されていないため、この記事では見込みとして扱いません。
書き込みを三つに分ける：可逆・補償・不可逆
A&Aの考え方
ここからはA&Aの設計です。出典が「破壊的な変更」と「機微な操作」という区別を置いているのを受けて、受託の範囲決めでは書き込みを三つに分けます。分類の基準は難しさでも権限の広さでもなく、取り消しの経路です。
A&Aの考え方
一つ目は可逆な書き込みです。対象システムに取り消しの手順があり、その取り消しを受託側が自分で実行できるもの。下書きの保存、ステータスの変更、タグの付け外し、メモ欄への追記などが入ります。間違えたら自分で戻せます。顧客に連絡して承認を待つ必要がありません。
A&Aの考え方
二つ目は補償が必要な書き込みです。その操作自体は取り消せないが、打ち消すための別の操作が用意されているもの。請求書を発行してしまったら返金する、通知を送ってしまったら訂正の通知を送る、在庫を引き当ててしまったら解放する。元には戻りませんが、帳尻は合わせられます。ただし打ち消す操作を実行するのが誰か、そしてその実行に承認が要るかは、システムではなく顧客の運用で決まっています。
A&Aの考え方
三つ目は不可逆な書き込みです。外に出たあとは取り消せないもの。顧客の顧客に届いたメール、実行された支払い、確定した出荷指示。打ち消す操作が存在しないか、存在しても相手に見えてしまった事実は消えません。ここに自動の書き込みを入れる場合、確認は実行の前に置くしかありません。あとから戻す経路がないからです。
A&Aの考え方
この三分類は、対象システムの機能一覧を見れば機械的に決まるものではありません。同じ「レコード更新」APIでも、更新した結果が社内にとどまるなら可逆、顧客の顧客に通知が飛ぶ設定になっているなら不可逆です。だから分類の作業は、APIの仕様書ではなく顧客の運用を見て行います。この点はA&Aの判断であり、出典はシステム設計の文脈で述べているだけです。
書き込み一件ごとに埋める四つの欄
A&Aの考え方
分類を決めるために、そして契約に書くために、書き込みの操作ごとに四つの欄を埋めます。一件につき四行、操作が五つあれば二十行です。この作業が終わっていない状態で工数だけ出すと、あとで増えるのは工数ではなく責任になります。
A&Aの考え方
一つ目の欄は取り消しの方法です。対象システムのAPIで取り消せるのか、管理画面から人が手で戻すのか、戻す手段がないのか。「たぶん戻せる」は空欄と同じ扱いにします。二つ目の欄は原状回復の担当者です。受託側か、顧客側の誰か、あるいは決まっていないか。ここが空欄のまま運用に入った書き込みが、あとで最も高くつきます。
A&Aの考え方
三つ目の欄は確認者と、その人が見る材料です。「顧客が確認する」では不足で、役割と、その人が判断に使える画面や通知を併記します。四つ目の欄は、失敗が見えるまでの時間です。実行した瞬間にエラーとして分かるのか、顧客の月末の締めで初めて食い違いとして出てくるのか、顧客の顧客からの申告で分かるのか。
A&Aの考え方
A&Aが最も抜けやすいと見ているのは四つ目の欄です。これは当社が数えた結果ではなく、範囲の決め方についての編集上の見方です。抜けていた場合に効くのは、三つ目の欄の設計です。実行の瞬間に分かる失敗なら、確認者は受託側でも成り立ちます。締めまで見えない失敗や、相手からの申告で分かる失敗は、受託側が気づけない位置にあるので、顧客側に確認者を置くか、そもそも自動の書き込みから外すしかありません。どちらを選ぶかが、最初の納品の範囲です。
出典に基づく事実
確認を実行の前に置くという考え方自体は、出典側にも現れています。Anthropicが2024年12月19日に公開したエージェント設計の記事は、エージェントが「チェックポイントや行き詰まったときに人のフィードバックのために止まる」（pause for human feedback at checkpoints or when encountering blockers）ことができるとし、最大の反復回数のような停止条件を入れて制御を保つのも一般的だと述べています。同記事は、価値が出るのは会話と行動の両方を要し、明確な成功基準と反応の循環があり、「意味のある人の監督を組み込んだ」（integrate meaningful human oversight）業務だとしています。
見積もりに増えるのは接続ではなく、取り消しの設計と確認者の時間
出典に基づく事実
同じエージェント設計の記事は、自律的に動かす場合の費用について明確です。開かれた問題に対してエージェントを使うなら「その判断に一定の信頼を置く必要がある」（you must have some level of trust in its decision-making）とし、自律性は「より高い費用と、誤りが積み重なる可能性」を意味するとしています。そのうえで「隔離された環境での十分な検証と、適切なガードレール」（extensive testing in sandboxed environments, along with the appropriate guardrails）を勧めています。
A&Aの考え方
A&Aの読み替えでは、書き込みを含めたときに見積もりへ乗るのは接続の工数ではありません。乗るのは四つです。取り消し手順の設計と文書化。実行前の確認を顧客が実際に押せる形にすること。隔離された環境での検証、つまり顧客の本番に書き込まずに同じ経路を通す場を作ること。そして失敗したときの連絡経路です。接続そのものは、読み取りだけの場合とほとんど変わりません。
A&Aの考え方
もう一つ、見積書に書かないが顧客に見せるべき費用があります。確認者の時間です。実行前の確認を入れるということは、顧客側の誰かが一件ごとに判断するということです。Chatbase事例の「一回のクリック」という記述は、クリックが一回なら負担が小さいという話に見えますが、件数を掛けると顧客の工数になります。どれだけ軽い確認でも、一日に何件来るかを掛け算して顧客に示さないと、運用に入ってから確認が溜まり、確認待ちの書き込みが止まります。人の確認がどこで詰まるかの見積もり方は「AI受託を増やす前に、人の確認で詰まる量を見積もる」で扱っています。
A&Aの考え方
逆に、自動の書き込みを入れないという選択が高くつく場面もあります。可逆な書き込みを人の手に残すと、顧客側の担当者が転記を続けることになり、転記のミスはそのまま顧客の負担です。だから可逆な書き込みは最初の納品に含めるのが標準で、含めないことを選ぶならその理由を書きます。この優先順位はA&Aの設計であり、出典が示した規則ではありません。
「読み取りまで」も無責任ではない：約束するのは提案の追跡可能性
A&Aの考え方
読み取りまでに絞ったとき、約束がゼロになるわけではありません。読み取りの出力は、人が行う書き込みの根拠になります。提案を見た担当者がそれを信じて入力するなら、提案の誤りは入力の誤りとして顧客のシステムに入ります。範囲を読み取りまでにしても、提案の品質に対する責任は残ります。
出典に基づく事実
ここで約束すべきものの手がかりも、ツール設計の解説にあります。同解説は、ツールの実装が返すべきなのは信号の強い情報だけであり、「柔軟性よりも文脈上の関連性を優先する」（prioritize contextual relevance over flexibility）べきで、uuidやmime_typeのような低水準の技術的な識別子は避け、nameやimage_urlのような、下流の行動と応答に直接結びつく項目を返すべきだと述べています。
A&Aの考え方
ここで注意すべき境界があります。この記述はツールがエージェントへ返す応答の設計についてのものであり、納品物が人に見せる情報の設計について述べたものではありません。そのうえでA&Aの読み替えでは、読み取りまでの納品で約束するのは追跡可能性です。すなわち、この提案はどのレコードを根拠にしているか、その参照はいつ時点のものか、参照できなかった項目は何か。この三つが提案に付いていれば、担当者は提案を検算できます。付いていない提案は、担当者にとって確認不能な指示になり、結果として全件を手で確かめ直すか、無検証で入力するかの二択になります。どちらも読み取りまでに絞った意味を消します。
架空の例：問い合わせから見積もり台帳への登録を請ける場合
仮想例
以下は架空の例で、実在の顧客や当社の実績ではありません。顧客は設備工事の会社で、問い合わせフォームとメールから来る引き合いを、社内の見積もり台帳に登録しています。受託する処理は、問い合わせ本文から現場の所在地、希望時期、工事の種別を取り出し、台帳に新規の行を作ることです。顧客は「どうせなら、担当者の割り当てと、お客様への受付のお知らせまで自動で」と言っています。
仮想例
書き込みは三つに分かれます。台帳への新規行の作成は可逆です。台帳には行の削除と編集があり、受託側のアカウントで実行できます。担当者の割り当ては補償が必要な書き込みです。割り当て自体は変更できますが、割り当て時に担当者へ通知が飛ぶ設定になっており、通知は取り消せないので、誤割り当てのときは訂正の連絡が必要になります。お客様への受付のお知らせは不可逆です。顧客の顧客に届いた時点で戻せません。
仮想例
四つの欄を埋めると、失敗が見えるまでの時間に差が出ます。台帳の行は、項目の取り違えがあっても顧客の担当者が台帳を見た時点で分かります。担当者の割り当ては、通知を受けた担当者が「これは自分の担当地域ではない」と気づけば分かります。受付のお知らせは、工事の種別を取り違えたまま送ると、お客様から違う工事の話として返信が来るまで分かりません。しかもその返信は受託側には届きません。
仮想例
だから最初の納品は、台帳への新規行の作成までとします。担当者の割り当ては、割り当て案を台帳の備考欄に書き込むところまでを可逆な書き込みとして含め、通知を伴う確定は顧客側の担当者が台帳から実行します。お客様へのお知らせは最初の契約から外し、台帳の行が三か月分たまって取り違えの傾向が見えてから、別の見積もりとして出します。見積書には、台帳の接続工数のほかに、取り消し手順の文書と、検証用の台帳の複製を作る工数を分けて書きます。
A&Aの考え方
A&Aがこの例で強調したいのは、顧客の要望を断っていない点です。三つのうち一つを最初に入れ、一つを可逆な形に落とし、一つを時期を決めて後回しにしています。断るのではなく、取り消しの経路がある順に並べ替えています。並べ替えの根拠を顧客に説明できるのが、この四つの欄の使いどころです。
この線引きが要らない条件と、主張しないこと
A&Aの考え方
この設計が不要になる場面があります。顧客の社内に既に承認のフローがある場合、確認者はそのフローの既存の承認者であって、受託側が新しい確認の段を作る必要はありません。確認を二重にすると、統制は増えずに納期だけ伸びます。また書き込み先が受託側で用意した基盤である場合、原状回復の担当は初めから受託側なので、問題は値付けだけに縮みます。
A&Aの考え方
件数も条件です。書き込みが月に数件なら、自動化と取り消し設計の工数を人の入力が上回ることはまずありません。この三分類は、同じ種類の書き込みが繰り返し発生する業務に向けた道具です。
出典に基づく事実
出典の性質と鮮度についても明示します。エージェント設計の記事は2024年12月19日の公開で、同ページには、この記事で述べた道具の状況の多くが2024年12月以降に変わったという注記が付いています（Much of the tooling landscape described in this post has changed）。この記事で引いたのは費用・誤りの積み重なり・隔離環境での検証という、特定の道具に依存しない記述に限っていますが、公開時期は古いものです。
A&Aの考え方
主張しないことを並べます。書き込みを可逆性で分類すると利益率が上がる、あるいは事故が減る、という因果はどちらの出典も示していません。A&Aもそれを測っていません。Chatbase事例の人の監督に関する記述は、監督を付けたという設計の説明であって、監督が機能した証拠ではありません。日本の受託契約における条項の有効性、契約不適合責任の扱い、読者の業界の監査要件への適合は、この記事の範囲外です。顧問にご確認ください。当社の見積もり精度や案件の利益率は提示しません。
次の一歩：いま迷っている一件で、取り消しの方法だけ書く
A&Aの考え方
四つの欄を一度に埋める必要はありません。いま「書き込みまで請けるか」で止まっている案件について、一つ目の欄だけ書いてみてください。その書き込みは、対象システムのAPIで取り消せますか。管理画面から人が戻せますか。それとも戻す手段がありませんか。三つ目に当たるなら、その操作は最初の納品の範囲ではなく、実行前の確認者を決める別の話です。
A&Aの考え方
最初の商品として売る業務単位をまだ決めていない段階なら「AI受託の最初の商品を決める：一人で売れる業務単位の切り出し方」が先に立ちます。顧客獲得から継続までの全体の流れは「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」にまとめています。書き込みの範囲を決めたうえで実装まで必要な場合は、開発としてお見積もりします。
読み取りと書き込みは同じ接続作業に見えますが、失敗したときに誰が原状回復するかが違います。Anthropicのツール設計の解説は、実装しない道具を選ぶことを第一の原則に置き、MCPのツール注釈は破壊的な変更を行う道具を申告する助けになると述べています。Chatbase事例は、請求書の確認と返金の処理を同じStripe連携のなかに並べ、機微な操作には任意で人の監督を付けるとしています。だから最初の納品の範囲は、取り消しの経路で決めます。受託側で取り消せる可逆な書き込みまでを標準とし、打ち消す操作が必要なものと、外に出たら戻せないものは、実行前の確認者と取り消し手順を決めてから別見積もりにする。見積もりに増えるのは接続工数ではなく、取り消し手順の設計、検証環境、そして顧客側の確認者の時間です。条項の法的な妥当性は、読者ご自身の顧問にご確認ください。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Writing effective tools for agents
Anthropic · 2025-09-11
確認日 2026-10-02 - Chatbase helps companies deliver instant, personalized customer support with Claude
Anthropic · undated customer story page; no publication date shown
確認日 2026-10-02 - Building effective agents
Anthropic · 2024-12-19
確認日 2026-10-02
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-10-02