API・開発
1 項目
API・開発とは｜このカテゴリで分かること
「生成AIのAPIの使い方を知りたい」「RAGとは何か、どう作るのか知りたい」という人のためのカテゴリです。チャット画面ではなく、自分のプログラムからAIモデルを呼び出してアプリや業務システムに組み込むまでに必要な知識を、Claude APIを中心に、OpenAIやGoogleにも共通する範囲で扱います。対象は、プログラミングの基礎があり、これからLLMアプリ開発を始める人から、本番運用で費用や品質に悩んでいる人までです。
カバーする範囲は大きく4つです。最初のリクエストを送るまでの基本、出力をプログラムで扱うための実装、社内資料を根拠に答えさせるRAG、そして費用・制限・評価・監視といった運用の話です。
はじめにおすすめの3本
迷ったら、まずこの3本から読んでください。残りの記事は、このページ下の項目一覧から、気になるテーマで選べます。
- 生成AI APIの基本｜アプリからAIモデルを呼び出す仕組みと最初の一歩
リクエストとレスポンスの基本形を、各社共通の言葉で先に押さえます。 - Claude API入門｜キー取得から最初のリクエストまで
キー取得から最初の1回までを実際に通し、全体の手触りをつかみます。 - APIキーの管理｜漏えいを防ぐ保管・権限・ローテーションの基本
コードを書き始める前に、キーの保管ルールを決めておきます。
追加学習が本当に必要かを判断したい場合は、最後に ファインチューニングの実践｜追加学習が必要かの判断・データ作り・評価の進め方 を読むと、RAGやプロンプトとの使い分けが整理できます。
押さえておきたいポイント
Anthropic・Googleの公式ドキュメントで確認できた、設計に影響する事実です（2026年10月時点で確認。仕様・料金・上限は変わるため、最新は公式で確認してください）。
| 項目 | 公式ドキュメントで確認できた内容 |
|---|---|
| リクエストの基本 | Claude APIは https://api.anthropic.com のREST API。Messages APIは POST /v1/messages。認証（APIキー）に加え anthropic-version と content-type ヘッダーが必須で、公式SDKはこれらを自動で付ける |
| レート制限 | 1分あたりのリクエスト数・入力トークン数・出力トークン数で管理され、超えると429エラーと、待つ秒数を示す retry-after ヘッダーが返る |
| 利用上限 | 利用ティアごとに月額の上限があり、自分で上限額を低く設定することもできる |
| バッチ処理 | Message Batches APIは通常より50%安く、多くは1時間以内に完了。24時間以内に終わらないリクエストは期限切れになる |
| プロンプトキャッシュ | 既定のキャッシュ有効期間は5分。読み出しは通常の入力単価より大幅に安い（倍率はモデルにより異なる） |
| キーの扱い（Google） | GeminiのAPIキーは、ソース管理に入れない、クライアント側に埋め込まずバックエンド経由で呼ぶ、が公式の推奨 |
よくある疑問
Q. RAGとは、ひと言でいうと何ですか？
A. 質問に関係する資料を検索して取り出し、それを根拠としてAIに回答させる仕組みです。学習していない社内情報や最新情報に答えさせたいときに使います。流れと失敗例は RAG（検索拡張生成）とは｜外部の資料を検索してAIの回答に活かす仕組み で解説しています。
Q. Claude APIの使い方は、何から始めればよいですか？
A. Consoleでアカウントを作ってAPIキーを発行し、公式SDKで最小のリクエストを送るのが最短です。手順は Claude API入門｜キー取得から最初のリクエストまで、キーの扱いは APIキーの管理｜漏えいを防ぐ保管・権限・ローテーションの基本 を先に読んでください。
Q. 費用が読めず不安です。
A. 入力・出力のトークン数に単価を掛けて見積もります。計算の手順は トークン料金の計算｜入力・出力の単価から費用を見積もる方法、削減策は プロンプトキャッシュ｜繰り返し使う長い入力の費用と遅延を減らす仕組み と バッチ処理（Batch API）｜急ぎでない大量のリクエストを非同期でまとめて処理する にまとめています。
Q. RAGとファインチューニングはどちらを選ぶべきですか？
A. 知識を足したいならRAG、口調や形式など振る舞いを変えたいなら追加学習、が一般的な切り分けです。判断基準は ファインチューニングの実践｜追加学習が必要かの判断・データ作り・評価の進め方 を参照してください。
編集部の見解
API開発は、最初の1回を動かすまでは簡単ですが、本番で問題になるのは費用・制限・品質の3つだと考えます。そのため、機能を増やす前に、評価用のデータと記録の仕組みを早めに用意することをおすすめします。RAGは「検索で正しい資料を取り出せているか」と「取り出した資料から正しく答えているか」を分けて確認すると、原因の切り分けが格段に楽になると考えます。また、モデルや料金は短い周期で変わるため、特定のモデル名や単価をコードや社内資料に固定せず、設定として差し替えられる作りにしておくのが長く使えるコツだと考えます。