10秒でいうと
動かすところまでは簡単です。難しいのは、失敗したときにどうするか。
出力が壊れる、上限に当たる、費用が読めない。この3つを先に設計してください。
第7章の締めくくりです。ここまでで、APIの呼び方（No.51）、機能（No.52）、費用（No.53）、エージェント化（No.54）を見ました。
最後は、実際に社内で動かすときの話です。
動かすのは簡単、続けるのが難しい
試作は1日でできます。本番で3か月動かすのが難しい。差は、失敗をどう扱うかにあります。
先に決めておくべき3つを挙げます。
出力が壊れたとき
構造化出力を使ってください（No.52）。これで形は保証されます。
ただし、形が正しいことと、中身が正しいことは別です。日付の欄に日付が入っていても、それが正しい日付とは限りません。
検算を組み込む。第4章のNo.33で書いた3つが、そのまま使えます。
- 件数：入力が5件なら、出力も5件か
- 端：最初と最後が妥当か
- 差分：前回の結果と比べて、変わり方が説明できるか
そして、読み取れなかったことを表現できる型にしてください。空文字ではなく null、あるいは「要確認」のフラグ。推測で埋まった値と、読めなかった値が区別できないのが、いちばんこわい状態です。
上限に当たったとき
レート制限には必ず当たります（No.51）。
すぐ再試行しない。間隔を空けて再試行する仕組みが各SDKに入っています。それを使ってください。
当たったときに何を返すかを決めておきます。エラーにするのか、順番待ちにするのか、前回の結果を返すのか。画面の向こうに人がいるなら、待たせるより「いま混んでいます」と返すほうが親切です。
急がない処理はバッチに逃がすのが本筋です（No.53）。リアルタイムで処理する必要が本当にあるのか、一度疑ってください。
費用が読めないとき
No.53の見積もりを立てたうえで、上限を設ける仕組みを入れてください。
- Consoleでワークスペースに支出の上限を設定する
- 自分のアプリ側でも、1日あたりの呼び出し回数を数える
- 利用者ごとの上限を設ける（自分のサービスに載せる場合）
3つ目が抜けると、1人の利用者の使い方で全体が止まります。
そして使用量の記録を残してください。応答の usage にトークン数が入っています。これを保存しておくと、あとで「どの処理が高いのか」が分かります。
キーの管理、もう一度
No.51で書いたことを繰り返します。キーをクライアント側に置かない。
自分のサービスに載せる場合、必ず自分のサーバーを経由してください。ブラウザやアプリから直接Claudeを呼ぶ作りにすると、キーが利用者に見えます。
サーバーを挟むと、上限の管理も、記録も、フィルタもそこに置けます。設計として自然な形です。
誰が責任を持つか
技術ではなく、運用の話です。ここを決めずに本番に出さないでください。
- 出力が間違っていたとき、誰が気づくのか
- 止めるのは誰の判断か
- 利用者に何と説明するのか
第3章のNo.22で書いたとおり、任せても責任は移りません。AIが出した結果だから、は理由になりません。
AIが関わっていることを利用者に伝えるかも決めておいてください。分野によっては、伝えないこと自体が問題になります。この話は第11章のNo.79で扱います。
小さく出す
最後に順番の話です。
- 社内の数人で使う
- 失敗の記録を集める（どういう入力で壊れたか）
- 検算を足す
- 範囲を広げる
2番目を飛ばさないでください。実際に来る入力は、想定と違います。見積書の仕事でいえば、様式の違う1社、スキャンが斜めの1枚、金額欄が空の1件。それが出てから設計するほうが、正確に作れます。
やってみよう：壊れ方を先に洗い出す（5分）
プロンプト
“`
次の処理をAPIで組んで本番運用します。
「起きうる失敗」を、原因ごとに分けて挙げてください。・入力の問題（想定外のデータ）
・出力の問題（形は正しいが中身が違う）
・環境の問題（上限、障害）
・運用の問題（誰も気づかない）それぞれについて、事前に組み込める対策も書いてください。
精神論ではなく、コードか仕組みで解決する案でお願いします。処理：（ここに書く）
“`期待される結果：4分類で失敗と対策が返る。4つ目の「誰も気づかない」がいちばん怖いことが見える。
うまくいかないとき：対策が「確認する」ばかりなら、「人の注意力に頼らない対策だけ」と足してください。第5章のNo.41と同じ話です。
つまずきポイント
試作の成功を本番の見込みにする。10件動いても、1万件では別のことが起きます。
読めなかった値を空で埋める。推測で埋まった値と区別できなくなります。
費用の上限を設けない。想定の10倍が請求される可能性を、設計に入れてください。
気づく仕組みを作らない。静かに間違え続ける仕組みは、本章を通していちばん危険な形です。
このあとどこへ進むか
開発ルートの本編はここまでです。第1章 → 第3章 → 第5章 → 第6章 → 第7章と読んできた方は、Claudeを使い、任せ、つなぎ、組み込むまでを一通り通ったことになります。
このあとは、目的に応じて2つの進み方があります。
- 運用に入る方 → 第11章 セキュリティとプライバシー（No.78）。渡してよいもの、社内ルールの作り方、そして間違いとの付き合い方（No.80）
- つくる方へ広げる方 → 第10章 個人開発：0から公開まで（No.77）
第8章（仕事で使う）と第9章（暮らしで使う）は、技術ではなく用途からの実践集です。順番に読む必要はないので、気になるページから開いてください。
まとめ
- 動かすのは簡単。難しいのは失敗の扱い
- 形が正しいことと、中身が正しいことは別。検算を組み込む
- 読めなかった値は、推測で埋まった値と区別できる形にする
- 誰が気づき、誰が止めるかを決めてから本番に出す
次に読む
※本記事の情報は 2026年8月時点のものです。