「API提供開始」というニュースは、そのAIを誰でも自分のサービスに組み込めるようになった、という意味です。
この一語が分かると、AIの発表がどこまで自分に関係するかを判断できるようになります。
この記事では、APIの説明を5つのレベルに分けて並べました。
どこから読むか
この記事は、同じ用語を5つのレベルに分けて解説しています。
当てはまるものを選んで、そこから読み始めてください。
→ この言葉を今日はじめて見た … Level 1から読む(3分)
→ 言葉は知っているが、人には説明できない … Level 2から読む(5分)
→ 説明はできるが、仕組みまでは怪しい … Level 3から読む(8分)
→ 仕事で使うかどうかを判断したい … Level 4から読む(10分)
→ 実装する、または技術記事を原典で読む … Level 5から読む(9分)
迷ったらLevel 1から読んでください。
知っている内容なら、数十秒で通り過ぎます。
1分で腕試し
理解度から決めたい場合は、次の4問を試してください。
Q1〜Q4は、Level 1〜4の内容に1問ずつ対応しています。
最初にまちがえた問題のLevelが、あなたのスタート地点です。
4問とも正解なら、Level 5から読んでください。
各レベルの終わりにも、4択の理解度チェックがあります。
ITパスポート試験の過去問題も入れています。
トークンという単位があやふやな場合は、先にこちらを読んでください。
→ トークンとは|AIの料金と文字数制限を決める単位
Q1.【オリジナル】ニュースで「あるAIのAPI提供開始」と報じられた。この意味として、最も適切なものはどれか。
- ア そのAIの中身(作り方)が、すべて公開された
- イ そのAIを、自分のアプリやサービスの中に組み込めるようになった
- ウ そのAIのチャット画面が、誰でも無料で使えるようになった
- エ そのAIを使うのに、インターネットがいらなくなった
正解:イ
解説:
APIは、プログラムどうしの注文口です。
API提供開始は、そのAIをプログラムから呼び出して、自分のサービスに組み込めるようになったという意味です。
ウは、チャット画面の話です。APIは画面ではなく、プログラムが使う入り口です。
アは、中身の公開(オープンソースやオープンウェイト)の話で、APIとは別です。
エは誤りです。APIは、ふつうインターネット経由で呼び出します。
→ まちがえたら Level 1から
Q2.【オリジナル】AIのAPIを使うための「APIキー」が、他人に知られてしまった。起こりうることとして、最も適切なものはどれか。
- ア 他人に勝手に使われ、その料金が自分に請求される
- イ キーは使い捨てなので、知られても影響はない
- ウ 自分が送った過去の質問が、すべて相手の画面に表示される
- エ 自分のパソコンが、遠隔で操作されるようになる
正解:ア
解説:
APIキーは、誰が使っているかを示す自分専用の合言葉です。
知られると、他人がそのキーで呼び出せてしまい、料金は自分に請求されます。
ウやエは、APIキーの役割とは関係がありません。
イは誤りです。キーは無効化するまで使い続けられます。気付いたら、すぐに無効化して作り直します。
→ まちがえたら Level 2から
Q3.【オリジナル】一般的なAPI(住所の検索など)と比べたとき、AIのAPIに特有の性質として、最も適切なものはどれか。
- ア 料金は、呼び出し回数だけで決まる
- イ 同じ要求を送っても、出力が毎回同じとは限らない
- ウ 呼び出すたびに、決まった形式の答えが一瞬で返ってくる
- エ 呼び出せる回数や量に、上限はない
正解:イ
解説:
AIのAPIは、同じ要求でも出力が変わり、形式が崩れることもあり、応答に数秒から数十秒かかります。
ウは、一般的なAPIの性質です。AIのAPIは遅く、形式も保証されません。
アは誤りです。AIのAPIは、処理したトークン数で課金されます。
エは誤りです。一定時間あたりの回数や量に上限があり、超えると断られます。
→ まちがえたら Level 3から
Q4.【オリジナル】業務でAIのAPIを使い始める。費用が跳ね上がる事故を防ぐために、最初に用意しておくべきものとして、最も適切なものはどれか。
- ア 高性能なモデルだけを使うようにする
- イ 請求書が届いてから、使いすぎを確かめる
- ウ 月額の上限を設定し、超えたら止まるようにしておく
- エ APIキーを1つだけ作り、全部署で共有する
正解:ウ
解説:
従量課金は、設計を誤ると請求が跳ね上がります。
上限があれば、使いすぎにも、負荷をかける攻撃にも、被害額に天井ができます。
イでは、気付いたときには費用が発生しています。
エでは、どこで使われたかを追えません。キーは用途や部署ごとに分けます。
アは逆です。高性能なモデルほど単価が高いので、費用は増えます。
→ まちがえたら Level 4から
Level 1 子供でもなんとなくわかる
ここはLevel 1です(全5レベル)
前提:なし。ここから読み始められます
想定読者:この言葉を今日はじめて見た人
このレベルのゴール:APIを「プログラムどうしの注文口」だと言える
レストランの注文口
レストランを思い浮かべてください。
お客さんは、厨房に入って自分で料理を作ったりしません。
店員さんに注文を伝えると、厨房で作られた料理が運ばれてきます。
お客さんと厨房の間にいる店員さん。
この「注文を受けて、結果を渡す係」にあたるものがAPIです。
- お客さん … 使う側のプログラム
- 店員さん … API
- 厨房 … 機能を持っている側(AIの本体など)
- 料理 … 返ってくる結果
プログラムどうしの注文口
APIは、プログラムどうしの間にある窓口です。
たとえば、スマホの天気アプリが天気を表示するとき、アプリが自分で空を観測しているわけではありません。
天気の情報を持っているところに「東京の天気を教えて」と頼み、返ってきた答えを画面に出しています。
この、頼んで答えをもらうための窓口がAPIです。
APIは Application Programming Interface の略です。
AIのAPIとは
AIにもAPIがあります。
「この文章を要約して」とプログラムから頼むと、要約された文章が返ってくる。
これが、AIのAPIです。
チャットの画面から使うのと違い、プログラムの中から自動で使えます。
だから、たくさんの仕事をまとめて頼むことができます。
「API提供開始」の意味
ニュースで「API提供開始」と聞いたら、こういう意味です。
そのAIを、誰でも自分のアプリやサービスの中に組み込めるようになった。
つまり、そのAIを使ったサービスが、これからたくさん出てくるということです。
つまずきポイント
「APIって、アプリの名前?」
違います。
画面を持った道具ではなく、プログラムが使う「入り口」の決まりごとです。
人が直接さわることは、ほとんどありません。
理解度チェック
Q1.【オリジナル】APIをレストランにたとえたとき、APIにあたるのはどれか。
- ア お客さん
- イ 注文を受けて、料理を運ぶ店員さん
- ウ 料理を作る厨房
- エ 運ばれてくる料理
正解:イ
解説:
APIは、使う側と機能を持っている側の間に立つ「注文口」です。
アのお客さんは、使う側のプログラムにあたります。
ウの厨房は、機能を持っている側(AIの本体など)にあたります。
エの料理は、返ってくる結果にあたります。
→ 「レストランの注文口」に戻る
Q2.【オリジナル】スマホの天気アプリが、東京の天気を表示するしくみとして、最も近いものはどれか。
- ア 利用者が入力した天気を、そのまま表示している
- イ 天気の情報を持っているところに頼んで、返ってきた答えを表示している
- ウ アプリが、自分で空を観測している
- エ スマホの中に、1年分の天気があらかじめ入っている
正解:イ
解説:
アプリは、天気の情報を持っているところに「東京の天気を教えて」と頼み、その答えを画面に出しています。
この「頼んで答えをもらう窓口」がAPIです。
ウ、エ、アのような作り方では、その日の天気を正しく出せません。
→ 「プログラムどうしの注文口」に戻る
Q3.【オリジナル】APIの説明として、最も適切なものはどれか。
- ア プログラムが機能を使うための、入り口の決まりごと
- イ 人が文字を打ち込んで、AIと会話するための画面
- ウ 画面を持った、スマホのアプリの名前
- エ AIを動かすための、特別なパソコン
正解:ア
解説:
APIは、プログラムが使う「入り口」の決まりごとで、人が直接さわることはほとんどありません。
イとウは、人が操作する画面の話です。
エは、機械の話です。APIは機械ではなく、やり取りの決まりです。
→ 「つまずきポイント」に戻る
Q4.【オリジナル】AIをチャット画面から使う場合と比べて、AIのAPIを使うよいところはどれか。
- ア 文字を打たずに、声だけで使える
- イ プログラムの中から自動で使えるので、たくさんの仕事をまとめて頼める
- ウ お金がまったくかからない
- エ AIの答えが、いつも正しくなる
正解:イ
解説:
APIなら、プログラムが自動で頼めるので、1件ずつ手で入力しなくて済みます。
エは誤りです。賢さは、どの入り口から使ってもモデルで決まります。
ウは誤りです。APIは、使った分だけ料金がかかるのが基本です。
アは、APIとは関係のない機能の話です。
→ 「AIのAPIとは」に戻る
Q5.【オリジナル】あるAIの「API提供開始」というニュースのあとに、起こりやすいこととして最も適切なものはどれか。
- ア そのAIを使ったアプリやサービスが、たくさん出てくる
- イ そのAIの答えが、すべて同じになる
- ウ そのAIを作った会社以外は、そのAIを使えなくなる
- エ そのAIのチャット画面が、使えなくなる
正解:ア
解説:
API提供開始は、そのAIを、誰でも自分のサービスに組み込めるようになったという意味です。
だから、そのAIを土台にしたサービスが増えていきます。
ウとエは、反対の方向の話です。
イは、APIとは関係がありません。
→ 「「API提供開始」の意味」に戻る
ここまで読めば言えるようになること
- APIを注文口のたとえで説明できる
- AIのAPIとチャット画面の違いを説明できる
- 「API提供開始」の意味を説明できる
言えたら、Level 2へ進む。
Level 2 少し理解できる
ここはLevel 2です(全5レベル)
前提:Level 1の内容(プログラムどうしの注文口、チャット画面との違い)
想定読者:言葉は知っているが、人には説明できない人
このレベルのゴール:チャット版とAPI版の違いを、扱える量と料金の仕組みで説明できる
同じAIに、入り口が2つある
同じAIを使うのにも、入り口が2つあります。
チャット版は、人が手で操作する入り口です。
ブラウザやアプリに文字を打ち込んで、回答を受け取ります。
API版は、プログラムが呼び出す入り口です。
別のソフトウェアがAIに指示を送り、結果を自動で処理します。
違いがはっきり出るのは、量が増えたときです。
1000件の問い合わせメールに返信の下書きを用意するなら、チャット版では1000回の操作が要ります。
API版なら、1000件を自動で送り、結果をまとめて受け取れます。
決められた形でやり取りする
APIには、決められた形があります。
「どんな形で頼むか」と「どんな形で返ってくるか」が、あらかじめ決まっています。
この決まりを守れば、どんなプログラムからでも使えます。
レストランの例でいえば、メニューにない料理は頼めません。
メニューに書かれた名前で頼めば、決まった料理が出てきます。
この決まりを書いた文書を、API仕様書と呼びます。
デジタル庁のガイドブックは、仕様書に含めるものをこう挙げています。
API仕様書には、API機能、API利用方法、エラーコード、リクエスト、レスポンス、提供データに関する説明が含まれます。
——デジタル庁「APIテクニカルガイドブック」(2024年9月30日)
AIのAPIで送るもの
AIのAPIに送るのは、主に次の4つです。
- 指示や質問:何をしてほしいか
- モデルの指定:どのモデルを使うか
- 設定:出力の長さの上限、ばらつきの度合いなど
- 鍵:誰が使っているかを示す文字列
最後の鍵は、APIキーと呼ばれます。
自分専用の合言葉のようなもので、他人に知られると勝手に使われ、その料金が自分に請求されます。
料金の仕組みが違う
チャットのサービスは、月額の定額制が多くなっています。
APIは、使った分だけの従量課金が基本です。
処理した量(トークン数)に応じて課金されるため、使わなければ費用は発生しません。
逆に、大量に使えば、それだけ請求されます。
実際の単価と、日本語で使ったときの費用の目安は、別の記事で時点つきでまとめています。
→ 主要AI APIの料金比較2026|日本語のトークン効率と試算
つまずきポイント
「APIがないAIは、使えないの?」
チャット画面からは使えます。
使えないのは、プログラムからの自動処理です。
高性能なモデルでもAPIが提供されていないことがあり、その場合は自社のサービスに組み込めません。
ニュースを読むときは、この点が実務上の分かれ目になります。
理解度チェック
Q1.【オリジナル】1000件の問い合わせメールに、返信の下書きを用意したい。チャット版とAPI版の違いの説明として、最も適切なものはどれか。
- ア チャット版は人が1000回操作し、API版はプログラムが1000件を自動で送って結果をまとめて受け取れる
- イ API版は1件ずつしか送れないので、チャット版のほうが速い
- ウ チャット版もAPI版も、人が1件ずつ操作する点は同じである
- エ 同じAIでも、API版のほうが答えの中身が賢くなる
正解:ア
解説:
同じAIでも、チャット版は人が手で操作する入り口、API版はプログラムが呼び出す入り口です。
違いがはっきり出るのは、量が増えたときです。
イとウは、API版の説明が違います。
エは誤りです。賢さはモデルで決まり、入り口では変わりません。
→ 「同じAIに、入り口が2つある」に戻る
Q2.【オリジナル】APIで「どんな形で頼むか」「どんな形で返ってくるか」などの決まりを書いた文書を、何と呼ぶか。
- ア 利用規約
- イ 取扱説明書(画面の使い方)
- ウ API仕様書
- エ プライバシーポリシー
正解:ウ
解説:
決まりを書いた文書がAPI仕様書です。
デジタル庁のガイドブックは、API機能、利用方法、エラーコード、リクエスト、レスポンス、提供データの説明を含むものとしています。
アの利用規約は、使ってよい条件や禁止事項を定めた文書です。
エは、個人情報の扱いを定めた文書です。
イは、人が画面を操作するための説明です。
→ 「決められた形でやり取りする」に戻る
Q3.【オリジナル】AIのAPIに送るもののうち、「誰が使っているか」を示す文字列はどれか。
- ア 指示や質問
- イ モデルの指定
- ウ APIキー
- エ 出力の長さの上限などの設定
正解:ウ
解説:
APIキーは、誰が使っているかを示す、自分専用の合言葉です。
他人に知られると勝手に使われ、その料金が自分に請求されます。
ア、イ、エは、何を、どのモデルで、どんな設定で頼むかを伝えるもので、利用者を示すものではありません。
→ 「AIのAPIで送るもの」に戻る
Q4.【オリジナル】APIの料金のしくみとして、最も適切なものはどれか。
- ア 月額の定額制で、どれだけ使っても同じ
- イ 使う人数で決まる
- ウ 処理した量(トークン数)に応じた従量課金が基本
- エ 呼び出した日数で決まる
正解:ウ
解説:
APIは、使った分だけの従量課金が基本です。
使わなければ費用は発生せず、大量に使えばそれだけ請求されます。
アは、チャットのサービスに多い料金の形です。
イとエは、APIの課金の単位ではありません。
→ 「料金の仕組みが違う」に戻る
Q5.【オリジナル】高性能なAIだが、APIが提供されていない。この場合に、できないことはどれか。
- ア チャット画面から質問すること
- イ そのAIの答えを読むこと
- ウ そのAIについてのニュースを読むこと
- エ 自社のサービスに組み込んで、プログラムから自動で使うこと
正解:エ
解説:
APIがなくても、チャット画面からは使えます。
できないのは、プログラムからの自動処理と、自社サービスへの組み込みです。
ニュースを読むときは、APIがあるかどうかが、実務で使えるかの分かれ目になります。
→ 「つまずきポイント」に戻る
ここまで読めば言えるようになること
- 同じAIに入り口が2つあると説明できる
- APIキーの役割と注意点を説明できる
- 従量課金の仕組みを説明できる
言えたら、Level 3へ進む。
Level 3 もう少し詳しく
ここはLevel 3です(全5レベル)
前提:Level 2までの内容(決まった形、APIキー、従量課金)
想定読者:人に説明はできるが、仕組みまでは怪しい人
このレベルのゴール:AIのAPIに特有の性質を挙げ、エンジニアとの会話に参加できる
やり取りの流れ
APIを使ったやり取りは、次の4段階です。
- 自社のプログラムが、決められた形で**要求(リクエスト)**を送る
- 相手のサーバーが要求を受け取り、APIキーを確かめてから処理する
- 結果が、決められた形で**応答(レスポンス)**として返ってくる
- 自社のプログラムが、その結果を使う
送受信の形式は、多くの場合JSONです。
名前と値の組を並べた、人にも読める形式です。
デジタル庁のガイドブックも、データ量が少なく処理の負荷が小さいことを理由に、応答にJSON形式を推奨しています。
AIのAPIに特有の5つの性質
一般的なAPIと比べたとき、AIのAPIには次の特徴があります。
1. 応答が遅い
住所の検索のような一般的なAPIは一瞬で返りますが、AIのAPIは数秒から数十秒かかります。
結果を待たせる画面では工夫が要ります。
2. 結果が毎回同じとは限らない
同じ要求でも、出力が変わります。
設定でばらつきを抑えられますが、完全には固定できません。
3. 出力の形式が保証されない
「JSONで返して」と指示しても、崩れた形式が返ることがあります。
検証と再試行の仕組みが必要です。
4. 量で課金される
呼び出し回数ではなく、処理したトークン数で課金されます。
長い文章を送れば、1回でも高くつきます。
5. 上限がある
一定時間あたりの呼び出し回数やトークン数に制限があります。
短時間に送りすぎると、「429 Too Many Requests」という応答で断られます。
デジタル庁のガイドブックは、このコードを「レート制限の超過」の場合に使うものとして説明しています。
1〜3はAIだから起きる性質で、4〜5は費用と量の性質です。
前の3つは設計で、後の2つは管理で対処します。
少しずつ返す方式
AIのAPIには、結果を一度に返す方式と、少しずつ返す方式があります。
少しずつ返す方式(ストリーミング)を使うと、生成の途中経過を画面に表示できます。
完了までの時間は変わりませんが、待たされる感覚が大きく減ります。
チャットの画面で文字が流れるように出てくるのは、この方式です。
自社で作り込む部分
APIを呼ぶだけで済むわけではありません。
実務では、次の作り込みが要ります。
- APIキーの安全な管理(プログラムに直接書かない)
- 失敗したときの再試行
- 上限に達したときの待機と再開
- 出力形式の検証
- 費用の記録と上限の設定
- 入出力の記録(あとから原因を追えるように)
見積もりを受け取ったら、これらが含まれているかを確認してください。
つまずきポイント
「APIを使えば、社内の情報を安全に扱える?」
APIを使うこと自体は、安全性を保証しません。
入力した内容がどう扱われるかは、規約と契約で決まります。
法人向けの契約では学習に使わないことが明示されていることが多く、そこを確認するのが実務です。
→ オプトアウトとは|ChatGPTなどAIに学習させない設定と、オフでも残ること
理解度チェック
Q1.【オリジナル】APIのやり取りで、送受信の形式として多く使われる、名前と値の組を並べた形式はどれか。
- ア JPEG
- イ PDF
- ウ MP3
- エ JSON
正解:エ
解説:
JSONは、名前と値の組を並べた、人にも読める形式です。
デジタル庁のガイドブックも、データ量が少なく処理の負荷が小さいことを理由に、応答にJSON形式を推奨しています。
イは文書、アは画像、ウは音声のファイル形式です。
→ 「やり取りの流れ」に戻る
Q2.【オリジナル】AIのAPIを呼び出したら、「429 Too Many Requests」という応答が返ってきた。最も適切な対応はどれか。
- ア 少し待ってから、間隔を空けて送り直す
- イ 入力の文章に誤りがあるので、書き直す
- ウ APIキーが漏れたと判断して、すぐに作り直す
- エ すぐに同じ要求を、何度も連続で送る
正解:ア
解説:
429は、短時間に要求を送りすぎて、レート制限を超えたことを示します。
待ってから、間隔を空けて送り直します。
エは、制限をさらに超えるだけです。
イとウは、別の原因に対する対応です。
→ 「AIのAPIに特有の5つの性質」に戻る
Q3.【オリジナル】AIのAPIの性質のうち、「AIだから起きる性質」に当てはまらないものはどれか。
- ア 応答に数秒から数十秒かかる
- イ 「JSONで返して」と指示しても、崩れた形式が返ることがある
- ウ 同じ要求でも、出力が毎回同じとは限らない
- エ 呼び出すには、APIキーで利用者を示す必要がある
正解:エ
解説:
APIキーで利用者を示すのは、AIに限らず多くのAPIに共通するしくみです。
ア、イ、ウは、AIのAPIだから起きる性質で、設計で対処します(応答の待たせ方、ばらつきの抑え方、検証と再試行)。
→ 「AIのAPIに特有の5つの性質」に戻る
Q4.【オリジナル】結果を少しずつ返す方式(ストリーミング)を使う利点として、最も適切なものはどれか。
- ア 出力が、毎回必ず同じになる
- イ 料金が、かからなくなる
- ウ 途中経過を表示できるので、待たされる感覚が減る
- エ 生成が完了するまでの時間が、半分になる
正解:ウ
解説:
ストリーミングでは、生成の途中経過を画面に出せます。
完了までの時間は変わりませんが、待たされる感覚が大きく減ります。
エは誤りです。速くなるのではなく、見え方が変わります。
アとイは、ストリーミングとは関係がありません。
→ 「少しずつ返す方式」に戻る
Q5.【IPA過去問】APIエコノミーに関する記述として，最も適切なものはどれか。
- ア インターネットを通じて，様々な事業者が提供するサービスを連携させて，より付加価値の高いサービスを提供する仕組み
- イ 著作権者がインターネットなどを通じて，ソフトウェアのソースコードを無料公開する仕組み
- ウ 定型的な事務作業などを，ソフトウェアロボットを活用して効率化する仕組み
- エ 複数のシステムで取引履歴を分散管理する仕組み
出典:令和3年度 ITパスポート試験 公開問題 問31
正解:ア
解説:
APIで公開された機能を部品のように組み合わせて、新しいサービスを作り、価値を広げていく経済の形がAPIエコノミーです。
AIのAPIも、この部品の一つです。「API提供開始」のあとに、そのAIを使ったサービスが増えるのは、このためです。
イはオープンソース、ウはRPA、エはブロックチェーンの説明です。
→ 「「API提供開始」の意味」に戻る
ここまで読めば言えるようになること
- やり取りの4段階を説明できる
- AIのAPIに特有の5つの性質を挙げられる
- 見積もりで作り込みの範囲を確認できる
具体的な単価と、日本語で使ったときの試算は、動向版にまとめています。
→ 主要AI APIの料金比較2026|日本語のトークン効率と試算
仕事で判断する立場なら、Level 4へ進む。
Level 4 ビジネスで使う
ここはLevel 4です(全5レベル)
前提:Level 3までの内容(AIのAPIに特有の性質、自社で作り込む部分)
想定読者:仕事で使うかどうかを判断したい人
このレベルのゴール:API利用の契約と費用を管理し、事故を防ぐ体制を作れる
各社の単価と、費用を下げる具体的な手は、時点つきで別記事にまとめています。
この節では、単価が変わっても変わらない「管理の型」を扱います。
→ 主要AI APIの料金比較2026|日本語のトークン効率と試算
契約で確認すること
APIを業務で使う場合、次を確認します。
入力データの扱い
学習に使われるか、保存期間はどれくらいか、保存場所はどこか。
プランによって条件が異なるため、契約するプランの規約を確認します。
データの所在地
処理が行われる地域を指定できるか。
業種や取引先の要求で、国内での処理を求められる場合があります。
モデルの廃止予告
使用中のモデルが廃止されるときの予告期間と移行期間。
これが短いと、突然の対応を迫られます。
デジタル庁のガイドブックも、呼び出し先を変える場合には「前もって開発者へ通知する」ことを求めています。
提供する側に予告の義務を課すのは、使う側にとってそれが死活問題だからです。
稼働率と障害時の扱い
サービスが止まった場合の業務への影響を、あらかじめ想定します。
利用規約上の禁止事項
生成物の用途や、対象業種に制限がないか。
APIキーの管理
APIキーの漏洩は、そのまま金銭的な被害になります。
デジタル庁のガイドブックは、APIキーの限界をはっきり書いています。
APIキーはコピーされアクセスされる可能性もあるため、強固な対策ではないことに留意する。
——デジタル庁「APIテクニカルガイドブック」(2024年9月30日)
鍵は「漏れる前提」で管理します。
- プログラムのコードに直接書かない
- 公開されるリポジトリに含めない
- 用途ごとに分け、不要になったら無効化する
- 定期的に作り直す
- 使用状況を監視し、想定外の増加に気付けるようにする
AIに渡す指示文(システムプロンプト)に鍵を書くのも禁物です。
総務省のガイドラインも、システムプロンプトに「機密情報(例:API キー)等を直接記述することを避け」ると書いています。
外部に委託する場合、委託先に渡すキーは委託先専用のものにし、契約終了時に無効化します。
費用の管理
従量課金は、設計を誤ると請求が跳ね上がります。
次の4つを仕組みとして持ってください。
1. 上限の設定
月額の上限をサービス側で設定し、超えたら止まるようにします。
2. 用途ごとの分離
APIキーを用途や部署ごとに分け、どこで使われているかを追えるようにします。
3. 日次の監視
費用を日次で確認し、急増に気付ける状態にします。
4. 見積もりとの突き合わせ
実績が見積もりとずれたら、原因を工程ごとに切り分けます。
多くの場合、会話履歴の積み上がり、指示文の長さ、再試行のどれかです。
費用の急増は、攻撃でも起こります。
総務省のガイドラインは、AIシステムに想定以上の計算負荷をかけて経済的な損失や応答の停止を起こす攻撃を挙げています。
上限の設定は、節約のためだけでなく、守りのためでもあります。
提供の経路を選ぶ
同じモデルでも、複数の経路で提供されていることがあります。
- 開発元が直接提供するAPI
- クラウド事業者を経由した提供
- 国内の事業者を経由した提供
選ぶときの観点は、データの所在地、契約の形、既存の調達手続きとの相性、価格です。
すでに契約しているクラウドの中で使えるなら、調達の手間が大きく下がることがあります。
事故を防ぐ設計
APIを組み込んだシステムでは、次を設計に含めます。
- 入力の検証:利用者の入力をそのままモデルに渡さない
- 出力の検証:形式と内容を確認してから後ろの処理へ渡す
- 権限の最小化:モデルに与えるツールや権限を必要最小限にする
- 記録:入力、出力、モデル、日時を残す
- 止める手段:問題が起きたときに、機能を止められるようにする
最後の項目は、あとから追加するのが難しいため、最初から入れておきます。
つまずきポイント
「委託先が使っているAPIの規約を確認していなかった」
システムを外部に委託した場合、実際にどのサービスのどのプランが使われているかは、明示的に確認しないと分かりません。
契約書に、使用するサービスとプラン、入力データの扱いを明記してもらう形にしてください。
理解度チェック
Q1.【オリジナル】業務で使っているAIのモデルについて、事業者から廃止の予告が届いた。契約の段階で確かめておくべきだったこととして、最も適切なものはどれか。
- ア モデルの名前の由来
- イ チャット画面の色やデザイン
- ウ 廃止の予告期間と、移行のための期間
- エ 事業者の本社の所在地
正解:ウ
解説:
予告期間と移行期間が短いと、突然の対応を迫られます。
デジタル庁のガイドブックも、呼び出し先を変える場合には前もって開発者へ通知することを求めています。
ア、イ、エは、業務の継続には関係しません。
→ 「契約で確認すること」に戻る
Q2.【オリジナル】APIキーの管理として、適切でないものはどれか。
- ア プログラムのコードにキーを直接書き、公開のリポジトリで共有する
- イ 定期的にキーを作り直す
- ウ 用途ごとにキーを分け、不要になったら無効化する
- エ 使用状況を監視し、想定外の増加に気付けるようにする
正解:ア
解説:
キーをコードに直接書いたり、公開の場所に置いたりすると、漏れたときにそのまま金銭の被害になります。
デジタル庁のガイドブックは、APIキーはコピーされうるので強固な対策ではない、としています。
キーは「漏れる前提」で管理し、ウ、エ、イのような運用をします。
→ 「APIキーの管理」に戻る
Q3.【オリジナル】APIの月額上限の設定が、節約だけでなく「守り」にもなる理由として、最も適切なものはどれか。
- ア 上限を設定すると、プロンプトインジェクションを防げる
- イ 上限を設定すると、出力の正確さが上がる
- ウ 上限を設定すると、APIキーが漏れなくなる
- エ 想定以上の計算負荷をかけて経済的な損失を起こす攻撃があり、上限があれば被害額に天井ができる
正解:エ
解説:
総務省のガイドラインは、AIシステムに想定以上の計算負荷をかけて、経済的な損失や応答の停止を起こす攻撃を挙げています。
上限は、こうした攻撃の被害を限られた額に抑えます。
ア、イ、ウは、上限の設定では防げません。それぞれ別の対策が要ります。
→ 「費用の管理」に戻る
Q4.【IPA過去問】ある銀行では，システムの接続仕様を外部に公開し，あらかじめ契約を結んだ外部事業者のアクセスを認めることによって，利便性の高い，高度なサービスを展開しやすくしている。このような取組を表す用語として，最も適切なものはどれか。
- ア BPO
- イ RPA
- ウ オープンAPI
- エ 技術経営
出典:令和6年度 ITパスポート試験 公開問題 問19
正解:ウ
解説:
接続の仕様(API仕様)を外部に公開し、契約した事業者に接続を認める取組が、オープンAPIです。
問題文の「あらかじめ契約を結んだ」が要点です。公開しても誰でも自由に使えるわけではなく、契約と鍵で利用者を管理します。
AIのAPIを使う側に立つときも、同じように契約の内容と鍵の管理が出発点になります。
アのBPOは業務の外部委託、イのRPAはソフトウェアのロボットによる定型作業の自動化、エの技術経営は技術を事業に生かす経営の考え方です。
→ 「契約で確認すること」に戻る
Q5.【オリジナル】AIを組み込んだシステムを外部に委託した。委託先が実際にどのサービスのどのプランを使っているかについて、最も適切な対応はどれか。
- ア 有名なサービスなら、どのプランでも同じなので確認しない
- イ 使用するサービスとプラン、入力データの扱いを、契約書に明記してもらう
- ウ 委託先に任せて、確認しない
- エ 完成したシステムの画面を見て判断する
正解:イ
解説:
どのサービスのどのプランが使われているかは、明示的に確認しないと分かりません。
プランによって、入力データの扱いや学習への利用の条件が変わります。
エは、画面からは分かりません。
アは誤りです。同じサービスでも、プランで条件が違います。
→ 「つまずきポイント」に戻る
ここまで読めば言えるようになること
- 契約時の確認項目を挙げられる
- APIキーの管理ルールを定められる
- 費用管理の4つの仕組みを設計できる
- 事故を防ぐ設計項目を挙げられる
実装に踏み込むなら、Level 5へ進む。
Level 5 専門的な話
ここはLevel 5です(全5レベル)
前提:Level 4までの内容
想定読者:実装する人、技術記事を原典で読みたい人
このレベルのゴール:信頼性と費用を両立する呼び出し方を設計できる
呼び出しの設計
タイムアウトは、用途ごとに設定します。
生成の長さに応じて必要な時間が変わるため、一律の短いタイムアウトは失敗を増やします。
ストリーミングを使う場合は、接続が切れたことと、受信が止まったことを分けて検出します。
再試行は、間隔を指数的に空け、ランダムな揺らぎを加えます。
複数の要求が同時に失敗したとき、揺らぎがないと再試行が同じ瞬間に集中するためです。
再試行してよいのは一時的な障害と上限到達で、入力の誤りによる失敗は何度送っても直りません。
冪等性(何度実行しても結果が同じになる性質)に注意が要ります。
生成は同じ要求でも結果が変わるため、再試行で処理が重複する危険があります。
外部に影響する処理では、要求の識別子で重複を取り除く仕組みを置きます。
上限への対処
大量に処理するときは、上限に当たることを前提に組みます。
- 要求をキューに入れ、上限に収まる速度で送り出す
- 応答に含まれる残量の情報を見て、送り出す速度を調整する
- まとめて処理する方式(バッチ)が提供されている場合、急がない処理はそちらへ回す
バッチは単価が下がる場合があり、夜間の一括処理に向きます。
出力の構造化
出力を後ろの処理で使う場合、形式の保証が要点です。
スキーマ(項目と型の定義)を指定して構造化出力を強制する機能があれば、それを使うのが最も確実です。
ない場合は、生成後にスキーマで検証し、失敗したら誤りの内容を伝えて作り直させます。
どちらの場合も、検証を通らなかった出力を後ろに流さない構成にします。
形式の崩れは、後段で原因の分かりにくい不具合として表に出ます。
費用と性能の最適化
キャッシュは、複数の要求が共通の長い先頭部分を持つ場合に効果があります。
割引や高速化を提供する事業者があり、活かすには先頭を固定する設計が要ります。
利用者ごとに変わる情報を先頭に置くと、この利点を失います。
モデルの振り分けは、費用対効果がもっとも大きい手段です。
処理の性質ごとに、軽いモデルと高性能なモデルを使い分けます。
軽いモデルで処理し、自信のない結果だけ上位に回す構成も有効です。
出力の制限は、上限トークン数の設定と、形式の明示で行います。
「前置きを書かない」という指示だけでも、出力トークン数ははっきり減ります。
観測
APIを組み込んだシステムでは、次を記録します。
- 要求と応答の全文(機微情報に配慮した保持期間で)
- 使用したモデルの識別子と版
- 入力トークン数と出力トークン数
- 応答時間(最初のトークンまでと、完了まで)
- 失敗の種別と再試行の回数
外部APIのモデルは、同じ名前のまま挙動が変わることがあります。
評価用の問題セットを定期的に流し、出力の変化を検知する運用を組み込んでください。
安全性
利用者の入力や、外部から取り込んだ文書をそのままモデルに渡す構成は、プロンプトインジェクションの入り口になります。
総務省のガイドラインは、細工したプロンプトを直接入力するものを「直接」、細工したデータを参照させるものを「間接」のプロンプトインジェクションとして分けています。
対策の軸は2つです。
一つは、LLMや連携するシステムを操作する仕組みの権限を必要最小限にすること(同ガイドライン)。
もう一つは、取り込んだ内容を指示として扱わない設計です。
モデルの出力で外部に影響する操作をする構成では、実行の前に確認を挟むか、実行できる操作を限定します。
出力をそのまま画面に表示する構成では、生成された内容が実行可能なコードとして解釈されないよう処理します。
理解度チェック
Q1.【オリジナル】AIのAPIの呼び出しが失敗したときの再試行で、間隔を指数的に空け、さらにランダムな揺らぎを加える理由として、最も適切なものはどれか。
- ア 揺らぎを加えると、料金が安くなるから
- イ 複数の要求が同時に失敗したとき、再試行が同じ瞬間に集中するのを避けるため
- ウ 揺らぎを加えると、出力が毎回同じになるから
- エ 揺らぎを加えると、APIキーの漏洩を防げるから
正解:イ
解説:
揺らぎがないと、同時に失敗した要求が同じ間隔で再試行され、また同じ瞬間に集中します。
ア、ウ、エは、再試行の間隔とは関係がありません。
→ 「呼び出しの設計」に戻る
Q2.【オリジナル】再試行しても直らない失敗はどれか。
- ア レート制限の上限に達したこと
- イ 事業者側の一時的な障害
- ウ 一時的なネットワークの切断
- エ 入力の形式の誤り
正解:エ
解説:
入力の誤りによる失敗は、何度送っても直りません。誤りを直してから送ります。
ア、イ、ウは一時的な原因なので、待ってから再試行すれば通る見込みがあります。
→ 「呼び出しの設計」に戻る
Q3.【オリジナル】生成AIのAPIで、外部に影響する処理(メールの送信など)を再試行するときに注意すべき点として、最も適切なものはどれか。
- ア 外部に影響する処理は、再試行の回数を増やすほど安全になる
- イ 再試行すれば必ず同じ結果になるので、何も対策はいらない
- ウ 生成は結果が毎回変わりうるので、再試行で処理が重複しないよう、要求の識別子で重複を取り除く
- エ 重複して送られても問題ないので、気にしなくてよい
正解:ウ
解説:
何度実行しても結果が同じになる性質を、冪等性といいます。
生成は同じ要求でも結果が変わるため、再試行で処理が重複する危険があります。
外部に影響する処理では、要求の識別子を使って重複を取り除きます。
イは誤りです。生成の結果は毎回同じとは限りません。
アとエは、重複の危険を見落としています。
→ 「呼び出しの設計」に戻る
Q4.【オリジナル】複数の要求が共通の長い先頭部分を持つとき、キャッシュの割引や高速化を活かす設計として、最も適切なものはどれか。
- ア 利用者ごとに変わる情報を、入力の先頭に置く
- イ 入力をできるだけ短く分割して、別々の要求にする
- ウ 毎回、入力の順番をランダムに入れ替える
- エ 入力の先頭部分を固定し、利用者ごとに変わる情報を後ろに置く
正解:エ
解説:
キャッシュは、共通の先頭部分を再利用するしくみです。
先頭を固定し、変わる情報を後ろに置くと、共通部分が保たれます。
アとウは、先頭が毎回変わるので、キャッシュの利点を失います。
イは、共通の先頭部分そのものがなくなります。
→ 「費用と性能の最適化」に戻る
Q5.【オリジナル】AIに参照させたウェブページの中に、細工された指示が埋め込まれていて、AIがそれに従ってしまった。総務省のガイドラインの分け方で、これにあたるものはどれか。
- ア 間接のプロンプトインジェクション
- イ 直接のプロンプトインジェクション
- ウ 構造化出力の失敗
- エ レート制限の超過
正解:ア
解説:
総務省のガイドラインは、細工したプロンプトを直接入力するものを「直接」、細工したデータを参照させるものを「間接」のプロンプトインジェクションとしています。
この例は、参照させたページに細工があったので、間接にあたります。
対策の軸は、連携する仕組みの権限を必要最小限にすることと、取り込んだ内容を指示として扱わない設計です。
ウとエは、攻撃の種類ではありません。
→ 「安全性」に戻る
ここまで読めば言えるようになること
- タイムアウトと再試行を用途に応じて設計できる
- 上限を前提にした大量処理を組める
- 出力の構造化と検証を実装できる
- 観測と安全性の項目を設計に含められる
APIの窓口を、自分で確かめたこと
私は前職のシステムエンジニアでの経験を生かして、AI分野の記事を書く仕事をしています。
その経験をもとに、このサイトを個人で立ち上げました。
前職では、多くのシステム間でデータをやり取りする開発に携わりました。
いちばん詰まったのはエラーのときに何が返ってくるかが仕様書に書かれていないものがあったことです。
本文で「仕様書にはエラーコードが含まれる」と書いたのは、そのときの経験からです。
2026年10月5日に、当サイトで使っているサービスの連携設定を開いてみました。
外部とつながっていたのは10本で、そのうち5本は、もう使っていないものでした。
つないだときのことは覚えていても、外すことは忘れていた、というのが正直なところです。
まとめ
APIは、プログラムどうしの注文口です。
Level 1では、注文を受けて結果を運ぶ係。
Level 2では、同じAIに用意された、プログラム用の入り口。
Level 3では、遅く、ばらつき、形式が保証されない特殊な相手。
Level 4では、鍵と費用を「漏れる前提」「跳ね上がる前提」で管理する対象。
Level 5では、再試行と検証で信頼性を作り込む実装対象。
「API提供開始」というニュースは、そのAIを土台にしたサービスが増えるという予告です。
そして使う側にとっては、鍵と上限の管理が始まるという合図でもあります。
次に読む記事
→ 主要AI APIの料金比較2026|日本語のトークン効率と試算
→ トークンとは|AIの料金と文字数制限を決める単位
→ AIエージェントとは|5段階でわかる用語解説
→ 今さら聞けないAI用語30選｜初心者でもニュースが読めるようになる意味と読み方
よくある質問(FAQ)
Q. APIとは何ですか?
A. プログラムどうしをつなぐ注文口です。決められた形で要求を送ると、決められた形で結果が返ってきます。Application Programming Interface の略です。
Q. 「API提供開始」はどういう意味ですか?
A. そのAIを、開発者が自分のサービスやアプリに組み込めるようになったという意味です。そのAIを土台にしたサービスが増える予告でもあります。
Q. APIとチャット画面の違いは何ですか?
A. チャット画面は人が1件ずつ操作しますが、APIはプログラムから自動で呼び出せます。大量の処理や、自社サービスへの組み込みができるようになります。
Q. APIの料金はどう決まりますか?
A. 処理したトークン数による従量課金が基本です。入力と出力で単価が異なり、一般に出力のほうが高く設定されています。具体的な単価は変わりやすいため、時点つきの記事(/ai-api-pricing/)で確認してください。
Q. APIキーが漏れたらどうなりますか?
A. 他人に使われ、その料金が自分に請求されます。気付いたらすぐにそのキーを無効化し、新しいキーを作り直してください。月額の上限を設定しておくと、被害額に天井ができます。
Q. 「429」というエラーが返ってきました。
A. 短時間に要求を送りすぎて、レート制限を超えたという意味です。少し待ってから、間隔を空けて送り直します。
この記事を書いた人:kkazuki｜AI/DX分野ブログ運営者 → 運営者情報
※APIの仕様や提供条件は、事業者ごとに異なり、変更されます。記述の時点をあわせて確認してください。
参考
- デジタル庁「デジタル社会推進実践ガイドブック DS-464-2 APIテクニカルガイドブック」(2024年9月30日) https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/fe5f0631-c978-42db-8416-6759cfa7e53a/f6ca1b7b/20241001_policies_development_management_outline_04.pdf
(API仕様書に含めるもの、JSON形式の推奨、APIキーは「強固な対策ではない」、429はレート制限の超過、ベースURIを変える場合の事前通知) - 総務省「AIのセキュリティ確保のための技術的対策に係るガイドライン」(令和8年3月) https://www.soumu.go.jp/main_content/001064122.pdf
(直接・間接のプロンプトインジェクション、権限を必要最小限にする、システムプロンプトにAPIキーを書かない、経済的な損失を生じさせる攻撃) - 総務省・経済産業省「AI事業者ガイドライン(第1.2版)」(令和8年3月31日) https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf
(AI開発者がAPI仕様の策定や入出力の設計を担うという役割の整理) - 本記事の体験の節は、筆者が自分で確かめた記録です(実施日は本文に記載)
