SaaSの価値は，単体で完結するだけでなく他のサービスとつながることで大きく広がる．外部ツールとの連携，ユーザー独自の自動化，将来のモバイルアプリ── これらを可能にするのがAPIだ．良いAPIは，サービスの拡張性そのものになる．

ただし，API設計は後から変えにくい．一度公開して外部に使われ始めたAPIを変更すると，それを使っている人たちのプログラムが壊れる．だから，最初から拡張に耐える設計をしておくことが，後々の自由度を大きく左右する．

この記事は，コア機能を実装し，APIの提供や設計を考え始める個人開発者に向けて書いている．REST設計の基本，リソースの考え方，認証，バージョニング，エラー設計，レート制限，そして使われるためのドキュメントまで，特定言語に依らず要点を解説する．

扱う範囲は，APIの意義 → 設計の基本(REST) → リソース指向 → 認証 → リクエストとレスポンス → エラー設計 → バージョニング → レート制限 → ドキュメント → Webhook提供 → よくある失敗，だ．読み終えたとき，あなたは拡張に強く，使われるAPIの作り方を理解している．

なぜ「API設計」に最初から気を配るべきか

APIは，あなたのサービスと外部世界との『契約』だ．一度『この形でデータをやり取りします』と公開すれば，それを信じて多くのプログラムがつながってくる．契約を勝手に変えれば，つながっていたものが一斉に壊れ，信頼を失う．

とくにSaaSでは，APIが差別化や顧客維持の武器にもなる．第3回で触れた『連携』による差別化や，ユーザーが自社の業務にあなたのサービスを組み込む(スイッチングコストになる)ことは，APIがあって初めて実現する．

また，内部的にも，フロントエンドとバックエンドをAPIで分離しておくと，将来モバイルアプリを作る・管理画面を別途用意するといった拡張がしやすくなる．最初から過剰にAPI化する必要はないが，設計の筋は通しておきたい．

本記事のメッセージは，『一貫性のある，予測可能で，変更に強いAPIを設計する』ことだ．派手さは要らない．使う人が『迷わず，驚かず，壊れず』に使えるAPIこそが，良いAPIである．そのための定石を，これから見ていこう．

API設計の基本 ― RESTという共通言語

Web APIの設計で，最も広く使われている流儀がREST(レスト)だ．RESTは厳密な規格というより設計のスタイルで，『リソース(データの単位)を，HTTPの仕組みに素直に乗せて操作する』という考え方を指す．多くの開発者が慣れているため，共通言語として使いやすい．

RESTの基本は，『何を(リソース)』をURLで表し，『どうする(操作)』をHTTPメソッドで表すことだ．ユーザー一覧を取得する，特定のユーザーを更新する，といった操作を，URLとメソッドの組み合わせで素直に表現する．

なぜRESTに従うかというと，『予測可能性』のためだ．RESTの慣習に従っていれば，使う人は『きっとこのURLでこう操作できるはず』と推測でき，学習コストが下がる．独自ルールのAPIは，いちいち調べないと使えず，嫌われる．

HTTPメソッド意味例
GET取得する一覧・詳細の読み取り
POST新規作成する新しいデータを作る
PUT/PATCH更新する既存データを変更
DELETE削除するデータを消す

RESTは万能ではなく，複雑な操作には別の流儀(GraphQL等)が向く場面もある．だが個人開発のマイクロSaaSでは，まずRESTで素直に設計するのが，開発者にも使う側にも分かりやすく，最も無難で確実な選択だ．

HTTPの仕組みに逆らわない

RESTの要点は，HTTPが元々持っている仕組み(メソッド，ステータスコード，ヘッダー)を素直に活用することだ．取得はGET，作成はPOST，成功は200番台，エラーは400・500番台── この当たり前を守るだけで，APIは格段に扱いやすくなる．

逆に，何でもPOSTで送る，成功でも失敗でも200を返す，といった『HTTPに逆らう』設計は，使う人を混乱させる．HTTPの作法に乗ることが，予測可能なAPIの第一歩だ．

まずは小さく公開する

APIも，第5回のMVPの発想と同じだ．最初から全機能のAPIを用意せず，本当に必要なリソースだけを小さく公開する．使われ方を見て，求められたものから足していく．

公開したAPIは変えにくいからこそ，最初は範囲を絞る．少ないが一貫したAPIの方が，多いが雑なAPIより，はるかに価値がある．削る勇気は，API設計でも有効だ．

リソース指向 ― URLは「モノ」を表す

REST設計の中心はリソース指向だ．URLは『操作』ではなく『モノ(リソース)』を表す．たとえば『/users』はユーザーという集合を，『/users/123』は特定のユーザーを表す．動詞(getUserなど)をURLに入れない．

操作は，前述の通りHTTPメソッドで表現する．『/users にPOST』で新規ユーザー作成，『/users/123 にGET』で取得，というように，『リソースのURL』と『メソッド』の掛け算で，必要な操作を整然と表せる．第9回のDB設計で『モノ単位でテーブルを分ける』と述べたが，APIのリソースも同じ発想だ．

リソースには階層関係もある．『ある組織のユーザー一覧』なら『/organizations/1/users』のように，所属関係をURLの階層で表現できる．第8回のマルチテナントの構造が，ここでも素直にURLに反映される．一貫した命名規則を決めておくことが，使いやすさの鍵だ．

命名は，複数形で統一する(/users)・小文字とハイフン・分かりやすい英単語といった慣習に従う．細かいことに思えるが，一貫した命名は『予測可能性』に直結する．一度ルールを決めたら，API全体で貫こう．

テナントの絞り込みを忘れない

APIでデータを返すときも，第8回で徹底したテナントの絞り込みは必須だ．『/users』が全テナントのユーザーを返してしまっては，重大な情報漏洩になる．APIは，認証されたユーザーのテナント範囲内のデータだけを返す．

URLにテナントを含めるか，認証情報から自動で絞るかは設計次第だが，いずれにせよ『他テナントのデータが取れない』ことを，APIレベルでも確実に保証する．Web画面と同じ防御を，APIでも貫く必要がある．

「動詞が欲しくなる操作」の扱い

『公開する』『送信する』のような，リソースにきれいに当てはまらない操作も出てくる．その場合は，その操作自体を一種のリソースとして表現する(例: /articles/1/publish へPOST)など，RESTの枠内で素直に表す工夫をする．

厳密さに囚われて不自然になるくらいなら，実用性を優先してよい．大切なのは『一貫していて，使う人が推測できる』こと．完璧なREST原理主義より，分かりやすさを取ろう．

APIの認証 ― 誰がアクセスしているかを確かめる

APIも，Web画面と同じく『誰がアクセスしているか』の認証が必要だ．ただし，APIはプログラムから呼ばれるため，ブラウザのログイン(セッション)とは別の方法が使われることが多い．代表的なのがAPIキーやトークンだ．

APIキーは，ユーザーごとに発行する『秘密の鍵』で，リクエストに添えることで本人を証明する．第7回で触れたトークン方式(ステートレス)が，APIではよく使われる．ユーザーが自分のAPIキーを発行・再発行できる画面を用意するのが一般的だ．

重要なのは，APIキーを安全に扱うことだ．キーは推測不可能な十分長いランダム文字列にし，保存時はハッシュ化し(第7回のパスワードと同じ発想)，通信は必ずHTTPSで暗号化する．キーが漏れれば，そのユーザーになりすまされてしまう．

APIの認証でも，第7回の認可の考え方は同じだ．認証(誰か)だけでなく，認可(そのキーで何ができるか)も確認する．そして，すべてのAPIアクセスで，テナントと権限の範囲を必ずチェックする．APIは外部に開かれている分，防御はより厳格に行いたい．

キーの再発行・失効を用意する

APIキーは漏洩しうる前提で，ユーザーが自分でキーを再発行・失効できる仕組みを用意する．漏れたと気づいたら即座に古いキーを無効化し，新しいキーに切り替えられる．これがあるだけで，漏洩時の被害を最小化できる．

複数のキーを発行できるようにすると，用途ごとに使い分けられて便利だ．とはいえ初期はシンプルに『1ユーザー1キー，再発行可能』から始めて十分．必要に応じて拡張しよう．

スコープで権限を絞る

より高度には，APIキーに『何ができるか』の範囲(スコープ)を持たせる．『読み取り専用キー』『特定の操作だけ可能なキー』のように権限を絞れば，万一漏れても被害を限定できる．

これも最初から作り込む必要はないが，APIを本格的に外部提供するなら，いずれ検討したい．最小権限の原則(必要な権限だけ与える)は，APIのセキュリティでも有効だ．

リクエストとレスポンスの設計 ― 一貫した形

APIでやり取りするデータの形式は，JSONが事実上の標準だ．リクエストもレスポンスもJSONで統一し，構造に一貫性を持たせる．使う人が『どのAPIでも同じ感覚で扱える』ことが，良いAPIの条件になる．

レスポンスは，成功時の形を統一する．データ本体をどのキーに入れるか，一覧のときのページング情報をどう返すか，といったルールをAPI全体で揃える．バラバラだと，使う側が毎回構造を確認する羽目になり，嫌われる．

日時や金額などのデータ型も，第9回のDB設計と同様に一貫した表現にする．日時はタイムゾーンを含む標準形式(ISO 8601等)で返す，金額は単位を明確にする，といった配慮で，使う側の誤解や不具合を防げる．一貫性こそが，APIの使いやすさの本質だ．

大量データを返すAPIでは，ページング(件数を区切って返す)を必ず入れる．第9回でも触れた通り，全件を一度に返すのは性能上危険だ．『何件目から何件』を指定できるようにし，レスポンスに総件数や次ページの情報を含めるのが親切な設計になる．

入力は厳しく検証する

APIは外部から任意のデータが送られてくる入口だ．受け取った入力は必ず検証し，不正な値は明確なエラーで弾く．第7回のセキュリティでも触れたが，入力検証は脆弱性を防ぐ基本であり，APIではとくに重要になる．

『来るはずのデータ』を信用せず，型・必須・範囲をチェックする．検証で弾いた理由を分かりやすくエラーで返せば，使う側もすぐ修正できる．厳格な入力検証は，安全性と使いやすさの両方に効く．

余計な情報を返しすぎない

レスポンスに，内部の実装詳細や，その用途に不要なデータを含めすぎない．とくに，他人の個人情報や内部IDなど，漏らすべきでない情報をうっかり返さないよう注意する．必要なものだけを返すのが，安全で軽いAPIだ．

『とりあえず全カラム返す』は，情報漏洩やデータ量増加のリスクになる．何を返し，何を返さないかを意識して設計することが，堅牢なAPIにつながる．

エラー設計 ― 失敗をきちんと伝える

良いAPIは，成功だけでなく失敗の伝え方が丁寧だ．エラーが起きたとき，何が悪かったのかが分からなければ，使う人は対処できず途方に暮れる．エラー設計は，APIの使いやすさを大きく左右する．

基本は，適切なHTTPステータスコードを返すことだ．認証が必要なら401，権限がなければ403，見つからなければ404，入力が不正なら400，サーバー側の問題なら500── このコードを見れば，エラーの大分類が即座に分かる．HTTPの作法に従うことが，ここでも効く．

さらに，レスポンス本文に，人間が読めるエラーの詳細を含める．『どのフィールドが，なぜ不正か』を具体的に返せば，使う側はすぐ直せる．エラーの形式もAPI全体で統一し，使う人が機械的に処理できるようにすると，なお親切だ．

注意したいのは，エラーメッセージに内部情報を漏らさないことだ．データベースの構造やスタックトレースをそのまま返すと，攻撃の手がかりになる．利用者には『何を直せばよいか』を，開発者向けには詳細をログに，と切り分けるのが安全だ．

エラーコードで機械処理を助ける

HTTPステータスに加え，アプリ独自のエラーコード(例: ‘invalid_email’)を返すと，使う側がプログラムでエラーの種類を判別しやすくなる．文言は変わってもコードは不変にしておけば，連携プログラムが安定する．

人間向けのメッセージと，機械向けのコードの両方を返すのが理想だ．これにより，APIを使う開発者は，エラーに応じた処理を確実に書ける．丁寧なエラー設計は，API提供者の親切さの表れだ．

成功なのに200以外，を避ける

ありがちな失敗が，本当はエラーなのにHTTP 200(成功)を返し，本文の中だけで失敗を伝える設計だ．これは使う側がエラーを検知しづらく，混乱の元になる．失敗は失敗のステータスコードで返すのが鉄則だ．

HTTPのステータスコードは，エラーハンドリングの第一の手がかりだ．これを正しく使うだけで，APIの信頼性と使いやすさは大きく向上する．成功と失敗を，コードで明確に区別しよう．

バージョニング ― 変更から利用者を守る

公開したAPIは変えにくい，と繰り返してきた．だが，サービスが進化すればAPIを変更したくなる場面は必ず来る．そのとき，既存の利用者を壊さずに変更を導入する仕組みがバージョニングだ．

最も一般的なのが，URLにバージョンを含める方法だ．『/v1/users』のようにし，互換性を壊す変更が必要になったら『/v2/users』を新設する．古いv1はそのまま残し，利用者が自分のタイミングでv2へ移行できるようにする．

個人開発の初期から複数バージョンを運用する必要はないが，最初から『/v1』を付けておくと，将来の変更に備えられる．これは小さな手間で大きな安心を得る，賢い先行投資だ．最初からバージョンの器を用意しておこう．

互換性を壊さない変更(項目の追加など)は，バージョンを上げずに行ってよい．バージョンを上げるのは，『既存の利用者のプログラムが壊れる変更』をするときだけだ．むやみにバージョンを乱立させず，互換性を保てる範囲では同じバージョンで進化させるのが，利用者にも優しい．

廃止は十分な猶予を持って

古いバージョンを廃止するときは，事前に告知し，十分な移行期間を設ける．いきなり停止すると，それを使っていた利用者のシステムが突然壊れる．第10回の課金や第8回のテナント削除と同じく，外部に影響する変更は猶予が鉄則だ．

APIは利用者との契約だという原点に立ち返れば，一方的な廃止が信頼を損なうことは明らかだ．誠実な移行支援が，API提供者としての信頼を守る．

レート制限 ― サービスを守る安全弁

APIを公開すると，大量のリクエストが来てサーバーが過負荷になるリスクがある．意図的な攻撃だけでなく，利用者のプログラムの不具合で無限にリクエストが飛んでくることもある．これを防ぐのがレート制限だ．

レート制限は，『一定時間あたりのリクエスト回数に上限を設ける』仕組みだ．上限を超えたら，一時的にリクエストを拒否(HTTP 429を返す)する．これにより，一部の利用者の暴走から，サービス全体と他の利用者を守れる．

個人開発でAPIを外部提供するなら，レート制限はほぼ必須の安全弁だ．無制限に開放すると，たった一つの暴走したプログラムで，サーバーが落ち，全顧客に影響が及ぶ．第8回で触れた『重いテナント』対策とも通じる，自衛の仕組みである．

レート制限をかけたら，その上限と，超えたときの挙動を利用者に伝える．レスポンスヘッダーで『残り何回か』を返すと，利用者は自分のプログラムを調整できる．制限は，利用者を締め出すためでなく，全体を守るためのものだと分かるよう，透明に運用しよう．

プランに応じた上限も可能

レート制限は，料金プランに応じて上限を変える使い方もできる．上位プランほど高い上限，というように．これは第4回の収益モデルと連動し，APIの利用量そのものを価値として課金する設計にもつながる．

ただし初期は，まず『全体を守る』ための一律の制限から始めれば十分だ．プラン別の細かな制御は，API利用が本格化してから検討すればよい．

ドキュメント ― 使われるための必須条件

どれだけ良いAPIを設計しても，ドキュメントが無ければ誰も使えない．APIは，使う人がドキュメントを読んで理解し，自分のプログラムに組み込むものだ．ドキュメントの質は，APIが実際に使われるかどうかを直接左右する．

良いAPIドキュメントには，各エンドポイントのURL・メソッド・パラメータ・レスポンス例・エラー例，そして認証方法が，具体的なサンプルとともに記載されている．とくに『動くサンプル(リクエストとレスポンスの実例)』があると，利用者の理解は格段に速くなる．

ありがたいことに，API仕様を記述する標準形式(OpenAPI等)があり，それに沿って書けば見やすいドキュメントを自動生成できるツールも揃っている．手書きで頑張るより，こうした仕組みに乗る方が，正確で保守しやすいドキュメントになる．

ドキュメントは，APIの変更と一緒に必ず更新する．実装とドキュメントがズレると，利用者は混乱し，信頼を失う．仕様から自動生成する仕組みにしておけば，このズレを防ぎやすい．『コードとドキュメントを一致させ続ける』ことが，長く使われるAPIの条件だ．

クイックスタートを用意する

ドキュメントの冒頭には，『最短でAPIを呼べるまで』を示すクイックスタートを置く．キーを取得し，最初の1リクエストを送り，結果が返ってくる── ここまでを数分で体験できれば，利用者の心をつかめる．

これは第23回のオンボーディングと同じ発想だ．最初の成功体験(アハ体験)を素早く届けることが，APIでも定着の鍵になる．詳細な網羅より，まず動かせる体験を優先しよう．

ドキュメントも公開の土台に載せる

APIドキュメントは，独自ドメインの分かりやすいURL(例: docs.自分のドメイン)で公開すると，信頼感も増し，利用者がアクセスしやすい．第13回で扱うドメイン運用の柔軟さが，ここでも活きる．

ドキュメントはサービスの顔の一つだ．きちんと整備され，見やすい場所に置かれていることが，API，ひいてはサービス全体の信頼につながる．地味だが，手を抜けない部分だ．

Webhookの提供 ― 「こちらから知らせる」連携

APIが『利用者がこちらに問い合わせる』仕組みなら，Webhookは『こちらから利用者に知らせる』仕組みだ．第10回で課金プラットフォームのWebhookを受け取る側を学んだが，今度はあなたが提供する側になる．

Webhookを提供すると，あなたのサービスで何かが起きたとき，利用者のシステムへ自動で通知できる．利用者は，変化がないか定期的に問い合わせる(ポーリング)必要がなくなり，リアルタイムに連携できる．これは強力な連携機能であり，差別化にもなる．

提供側として気をつけるのは，第10回で受け取り側として学んだことの裏返しだ．署名を付けて正当性を証明できるようにし，相手が受け取れなかったときの再送を用意し，相手のサーバーが遅くても自分が影響を受けないよう非同期で送る．受け取る側の苦労を知っていれば，親切な提供ができる．

Webhookは高度な機能なので，個人開発の初期から必須ではない．まずは基本的なREST APIを整え，利用者から『リアルタイム連携したい』という要望が出てきたら提供を検討する．第5回のMVPの発想通り，需要を見てから作ればよい．

利用者がWebhook先を登録できるように

Webhookを提供するなら，利用者が『通知を受け取るURL』を自分で登録・変更できる画面が要る．どのイベントを通知するか選べるようにすると，なお使いやすい．これらの管理機能も，APIやWebに用意する．

提供するイベントの種類は，最初は主要なものに絞ってよい．利用者の要望を聞きながら，本当に使われるイベントを増やしていく．ここでも『小さく始めて育てる』が有効だ．

API設計でやりがちな失敗

最後に，個人開発のAPI設計でありがちな失敗を確認しよう．いずれも，利用者を混乱させたり，将来の自分を縛ったりするものだ．

  • 命名やレスポンスが一貫しない：使う人が毎回調べる羽目になり嫌われる
  • エラーで200を返す：失敗が検知しづらく混乱を招く
  • バージョンを付けずに公開：変更で既存利用者を壊す
  • テナント絞り込みを忘れる：他人のデータが漏れる重大事故
  • ドキュメントが無い・古い：そもそも使われない・信頼を失う

共通する教訓は，『一貫性・予測可能性・変更への強さ・そして使われるためのドキュメント』だ．APIは利用者との契約であり，外部に開かれたサービスの顔．誠実で分かりやすい設計が，連携による価値の拡大と，顧客の定着をもたらす．

公開前にAPIのセキュリティを点検する

API公開前に，『認証は必須か・テナントと権限の絞り込みは漏れていないか・レート制限はあるか・エラーで内部情報を漏らしていないか・入力検証は十分か』を点検しよう．APIは外部に開かれている分，Web画面以上に防御を固めたい．

とくにテナント越境(他人のデータが取れる)は，Web画面で対策していてもAPIで漏れることがある．第8回の越境テストを，APIに対しても必ず行ってから公開しよう．

補論 ― APIとドキュメントを「信頼される場所」で提供する

APIは外部の開発者がプログラムからアクセスするものだけに，その提供基盤の安定性と信頼性が一層重要になる．応答が遅い・不安定なAPIは，連携先のシステムごと不安定にしてしまい，信頼を損なう．

安定したAPIを提供するには，自分で制御できる土台が心強い．高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─のような高速で信頼性の高いVPSなら，APIの応答速度やレート制限を自分の管理下で最適化でき，Webhook送信のような非同期処理も安定して動かせる．そして，API本体やドキュメントの分かりやすいURL(api.自分のドメインやdocs.自分のドメイン)を運用するための独自ドメインは，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─で取得し，用途ごとにサブドメインを柔軟に切れるようにしておこう．信頼されるAPIは，独自ドメインと安定した土台の上に成り立つ．

『一貫した設計のAPIを，分かりやすいドキュメントとともに，信頼される土台の上で提供する』── これがSaaSの拡張性を広げる正解だ．これで開発フェーズは完了．いよいよ，作ったサービスを世界に公開する番だ．次回からは公開フェーズ，まずは『独自ドメインの取得とブランディング』を解説する．

よくある質問(FAQ)

Q1．APIはRESTで設計すべきですか？

個人開発のマイクロSaaSでは，まずRESTで素直に設計するのがおすすめです．多くの開発者が慣れているため共通言語として使え，HTTPの仕組み（メソッド・ステータスコード）に素直に乗せることで予測可能性が高まります．複雑な操作にはGraphQL等が向く場面もありますが，RESTが最も無難で確実な選択です．

Q2．URLはどう設計すればいいですか？

URLは『操作』ではなく『モノ（リソース）』を表します．/usersのように複数形で統一し，特定のものは/users/123，所属関係は/organizations/1/usersのように階層で表現します．操作はHTTPメソッド（GET/POST/PUT/DELETE）で表し，動詞をURLに入れません．一貫した命名規則を決めて全体で貫くことが使いやすさの鍵です．

Q3．APIの認証はどうすればいい？

プログラムから呼ばれるため，ブラウザのセッションではなくAPIキーやトークンが一般的です．推測不可能な十分長いランダム文字列にし，保存時はハッシュ化，通信は必ずHTTPS．ユーザーが自分でキーを再発行・失効できる仕組みを用意し，すべてのアクセスでテナントと権限の範囲を厳格にチェックします．

Q4．最初からAPIのバージョンを付けるべき？

はい，最初から『/v1』を付けておくことをおすすめします．公開したAPIは変えにくく，互換性を壊す変更が必要になったとき，/v2を新設して古いv1を残せば既存利用者を壊さず移行してもらえます．小さな手間で将来の大きな安心が得られる，賢い先行投資です．

Q5．エラーはどう返すのが親切ですか？

適切なHTTPステータスコード（401認証要・403権限なし・404未発見・400入力不正・500サーバーエラー）を返し，本文に人間が読めるエラー詳細とアプリ独自のエラーコードを含めます．『本当はエラーなのに200を返す』のは厳禁です．ただし内部情報（DB構造やスタックトレース）は漏らさず，詳細はログに記録します．

Q6．レート制限は必要ですか？

APIを外部提供するならほぼ必須の安全弁です．一定時間あたりのリクエスト上限を設け，超えたら一時的に拒否（HTTP 429）します．一つの暴走したプログラムでサーバーが落ちて全顧客に影響するのを防げます．上限と残り回数を利用者に伝えると，相手も自分のプログラムを調整できます．

Q7．ドキュメントはどこまで必要ですか？

ドキュメントが無ければAPIは使われません．各エンドポイントのURL・メソッド・パラメータ・レスポンス例・エラー例・認証方法を，動くサンプルとともに記載します．OpenAPI等の標準形式で書けば見やすいドキュメントを自動生成でき，実装とのズレも防げます．最短で呼べるクイックスタートを冒頭に置くと定着率が上がります．

Q8．Webhookの提供は最初から必要ですか？

初期から必須ではありません．まず基本のREST APIを整え，利用者から『リアルタイム連携したい』という要望が出てから検討すれば十分です．提供する際は，署名で正当性を証明し，再送を用意し，非同期で送る（第10回で受け取り側として学んだことの裏返し）と，相手に親切な提供になります．

まとめ ― 一貫して，予測可能で，壊れないAPIを

APIは，あなたのサービスと外部世界との契約であり，拡張性と顧客維持を左右する武器だ．一度公開すると変えにくいからこそ，最初から一貫性のある，予測可能で，変更に強い設計を心がけたい．

鍵は，『RESTで素直に』『リソース指向でURLを設計』『認証とテナント絞り込みを厳格に』『エラーをコードで明確に』『最初からバージョンを付ける』『レート制限で守る』『使われるドキュメントを整える』ことだ．

派手さは要らない．使う人が『迷わず，驚かず，壊れず』使えるAPIこそが，良いAPIだ．そして，それを分かりやすいドキュメントとともに，信頼される土台の上で提供することが，連携による価値拡大をもたらす．

これで認証・課金・メール・APIという開発フェーズは完了だ．あなたのサービスは，いよいよ世界に公開できる状態になった．次回からは公開フェーズ．まずは，サービスの顔となる『独自ドメインの取得とブランディング』を解説する．