APIとは？アプリ開発者でない人のための入門ガイド

API（Application Programming Interface）は、あるソフトウェアが別のソフトウェアにデータを求めたり、何かをさせたりするための決まった方法です。アプリは「明日の予約を見せて」「このカードに20ユーロを請求して」「このテキストを要約して」といったリクエストを合意された形式で送り、相手のシステムは構造化されたレスポンスを返します。APIは、アプリの各部分が互いに通信する仕組みであり、アプリが決済、メール、地図、AIといった外部サービスを使う仕組みでもあります。

AIで作る場合になぜAPIが重要なのか

役に立つアプリのほとんどは、APIを通じて通信する部品で作られています。

• アプリの内部では、 ブラウザ上の画面が、自分のバックエンドのAPIを呼び出してデータを読み込んだり保存したりします。
• アプリの外部では、 バックエンドが他社のAPIを呼び出します。決済を受け付けるStripe、領収書を送るメールプロバイダー、テキストを生成するAIモデルのプロバイダーなどです。

AIビルダーに「支払いを受け付けて」「AIの要約を追加して」と頼むと、実際にはAPIを呼び出すコードを書いてくれています。基本を知っておくと、AIがあなたに何を必要とするか（通常は、そのサービスのアカウントとAPIキー）、どこでうまくいかなくなりうるか、そしてどれくらい費用がかかるかを理解しやすくなります。

身近なたとえ

レストランを考えてみてください。あなたは厨房に入って料理をするわけではありません。メニューを読み、キッチンが理解できる形で注文を伝え、ウェイターが料理を運んでくるか、「売り切れです」と伝えてきます。

• メニュー はAPIのドキュメントです。何を頼めるか、どのように頼むかの一覧です。
• ウェイター がAPIです。リクエストが入り、レスポンスが出ていく、合意された唯一の方法です。
• 厨房 は相手のシステムです。内部の仕組みを知る必要はありません。
• あなたの注文 がリクエストで、届いた料理 がレスポンスです。

メニューが変わらない限り、厨房は、オーブンやスタッフを変えてもあなたには影響しません。これがAPIの本当の価値です。どちらのシステムも、相手がどのように作られているかを知らなくても、一緒に働けるのです。

Webリクエストの仕組み

あなたが出会うAPIのほとんどは、ブラウザも使っているHTTPで動くWeb APIです。それぞれのリクエストには、いくつかの部分があります。

そして、それぞれのレスポンスには次のものがあります。

JSON（JavaScript Object Notation）は、波括弧の中に名前と値を並べる簡単なテキスト形式です。Web APIがデータをやり取りする標準的な方法です。

REST：最もよく使われる方式

RESTは、Web APIを設計するための広く使われた決まりごとです。それぞれの種類のものに独自のURLがあり、標準的なメソッドが、それに対して何をするかを示します。予約アプリのREST APIは、次のような形になるかもしれません。

PUT もありますが、慣習的にはレコード全体を置き換えるのに対し、PATCH は送ったフィールドだけを変更します。

よく見るステータスコードは次のとおりです。

アプリが壊れたとき、ステータスコードは多くの場合、最も速い手がかりになります。決済プロバイダーからの 401 は、通常、APIキーがないか誤っていることを意味し、429 は呼び出しが多すぎることを意味します。

RESTだけがスタイルではありません。GraphQLやRPC形式のAPIもありますが、多くのサービスやAIで作られたバックエンドで使われているのはRESTです。

具体例：予約の確認

サロンの予約アプリで顧客がヘアカットを予約するとき、1〜2秒の間に複数のAPI呼び出しが行われるかもしれません。

1. ブラウザ上の予約ページが、サービス、時間、顧客の詳細を含む POST /api/bookings をバックエンドに送ります。
2. バックエンドは、その枠が空いているかを確認し、予約をデータベースに保存して、201 Created を返します。
3. バックエンドは、秘密のキーを使って、メールプロバイダーのAPIを呼び出します。「この確認メールを lena@example.com に送って」という内容です。
4. 手付金が必要なら、バックエンドは決済プロバイダーのAPIに、チェックアウトのセッションを作成するように頼み、顧客をそこに案内します。
5. あとで決済プロバイダーが、支払いが成功したことを あなたの アプリに伝えるために呼び出してきます。この逆方向の呼び出しが Webhook です。

最初の2ステップは、フロントエンドとバックエンドの間にある、あなた自身のAPIです。ステップ3から5は、外部サービスのAPIです。

よく使われる用語の説明

よくある間違いと誤解

• 秘密のキーをフロントエンドに入れる。 ブラウザで動くコードに入っているものは、そのサイトを訪れた誰でも見られます。秘密のキーは必ずサーバー上に、環境変数またはシークレットとして置いてください。
• チャットにキーを貼り付ける。 チャットの履歴は保存されることがあります。代わりに、ビルダーのシークレット機能を使い、漏れたキーは必ず再発行（ローテーション）してください。
• APIは無料だと思い込む。 多くのAPIは、リクエストごと、または使用量ごとに課金します。AIモデルのAPIはトークン単位で課金されます。料金を確認し、支出の上限を設定してください。LLMのAPIの使い方 をご覧ください。
• 失敗を想定しない。 外部のサービスは停止したり、タイムアウトしたり、上限に達したりします。分かりやすいエラーメッセージと、再試行の仕組みを頼みましょう。
• ブラウザを信用しすぎる。 自分のAPIは、権限を自分でチェックする必要があります。ボタンを隠しても、エンドポイントを直接呼び出されるのは防げません。
• テスト中に本番のキーを使う。 本番公開の準備ができるまで、テストモードのキーを使いましょう。

AIビルダーへの頼み方

• 「このアプリはどの外部APIを使っていますか？ それぞれの費用はいくらですか？」
• 「決済のAPIはサーバーからだけ呼び出してください。キーは環境変数から読み込んでください。」
• 「私たちのAPIにあるすべてのエンドポイントを一覧にして、それぞれの役割と、誰が呼び出せるかを教えてください。」
• 「予約を更新または削除する前に、ログインしているユーザーがその予約の持ち主であることを、サーバー側で確認してください。」
• 「メールAPIが失敗しても予約は保存し、エラーをログに残してください。」
• 「今のところは、提供元のテストモードを使ってください。」

MythexでのAPI

Mythexは、自分のAPIを作ることができます。ウェブアプリの一部として作ることも、フロントエンドと並んで動くNode、Python（FastAPI）、C#、Javaの独立したバックエンドとして作ることもできます。また、外部サービスを呼び出すコードも書けます。APIキーは、チャットではなくプロジェクトのシークレットとして追加します。そうすれば、プレビューでも公開後でも、アプリから使えるようになります。ドキュメントには、任意のAPIを連携する と REST APIバックエンドを作る のレシピがあります。

よくある質問