（演習）開発テーマに沿った実装①

• 日程: Day 4 / セッション3
• 時間: [9:50-11:20]
• 形式: 実習
• ゴール: 情報の設計（情報モデル）とシステムの設計（実装）を分離した形で、開発テーマのAPI部分を実装できる
• 学習形式: AIペアプログラミング

🗣️ 要約

• Day2の情報モデル一覧・状態遷移図・機能一覧を見ながらAPI部分を実装する
• 「情報の設計」と「システムの設計」を分離する考え方を、実際のコードの形にする
• セッション終了時には、情報モデルに対応するAPIエンドポイントが動く状態になる

先ほどのセッションで、apiaryのモックAPIを作って呼び出す体験をしましたね。「動いた！」という感覚を持てたでしょうか。

ここからは、いよいよ自分たちの開発テーマに取りかかります。ここで少し考えてみてください。Day2で作った「情報モデル一覧」「状態遷移図」「機能一覧」は、今どこに眠っていますか？ 手元にありますか？

このセッションでは、その資料を見ながらAPI部分を実装します。ただし、ただ動くコードを書くのではありません。「情報の設計」と「システムの設計」を分離する、というDay2〜Day3で学んだ考え方を、実際のコードの形にします。このセッションが終わる頃には、開発テーマの情報モデルに対応するAPIエンドポイントが、実際に動く状態になっています。

🗣️ 要約

• 情報モデルの状態遷移がそのままAPIの設計図になる
• RESTful APIではエンドポイント名に情報（名詞）、HTTPメソッドに操作（動詞）を対応させる

🗣️ 要約

• Day2の状態遷移から抽出したCRUDがそのままAPIの設計図になる
• 情報の設計（レシピ）とシステムの設計（調理器具）は別物で、実装言語が変わっても情報の設計は変わらない
• 情報モデル自体（例：支出）は該当し、情報モデルに対する操作（例：合計金額を計算するボタン）は該当しない

Day2で、情報モデルの状態遷移からCRUD（新規入力・1件表示・一覧表示・更新・削除）を抽出しましたね。あの表がそのまま、今日実装するAPIの設計図になります。

これは、いわば「レシピ（情報の設計）」と「調理器具（システムの設計）」を分けて考えるようなものです。レシピは「何を、どの順番で、どれだけ」を決めるものであり、鍋がガラス製でも鉄製でも、レシピ自体は変わりません。同じように、「ユーザーという情報には名前・メールアドレスという属性があり、登録・参照・更新・削除ができる」という設計は、それをNode.jsで実装しようがPythonで実装しようが変わらないはずです。

具体的には、次のような対応関係になります。

• 情報モデル「家計簿の支出」→ 該当します。属性（金額・日付・カテゴリ）を持ち、CRUDの対象になるからです
• 「合計金額を計算するボタン」という機能そのもの → 該当しません。これは情報モデルではなく、情報モデルに対する「操作（機能）」だからです。なぜ両者を分けるのか、少し考えてみてください。ボタンの見た目やクリック方法を変えても、支出という情報の構造自体は変わらない、という点に気づけたでしょうか。

ここまでで、情報モデルとAPIエンドポイントの対応関係についてイメージできましたか？ 分からない場合は、AIに「私たちの情報モデル◯◯を、CRUD操作でAPIエンドポイントに変換すると、どういう構成になる？」と聞いてみましょう。

🗣️ 要約

• 状態遷移図の「状態」がデータの中身、「遷移」がCRUD操作に対応する
• REST APIではHTTPメソッド（GET/POST/PUT/DELETE）とURLで一覧・単件表示・新規登録・更新・削除を表す

状態遷移図の「状態」がデータの中身、「遷移（矢印）」がCRUD操作に対応します。これをREST APIの作法（HTTPメソッド＋URL）に落とし込むと、次のような形になります。

GET    /items          一覧表示
GET    /items/:id      1件表示
POST   /items          新規入力
PUT    /items/:id      更新
DELETE /items/:id      削除

items の部分を、皆さんの情報モデルの名前（例：expenses、recipes、bids など）に置き換えれば、そのままAPI設計の骨格になります。

apiaryでモック定義を書くときのイメージです（Blueprint記法の一部）。

## 支出一覧 [/expenses]
### 一覧を取得する [GET]
+ Response 200 (application/json)
    [
        { "id": 1, "date": "2026-08-01", "amount": 1200, "category": "食費" }
    ]

### 支出を登録する [POST]
+ Request (application/json)
    { "date": "2026-08-24", "amount": 800, "category": "交通費" }
+ Response 201 (application/json)
    { "id": 2, "date": "2026-08-24", "amount": 800, "category": "交通費" }

特に注意してほしいのは、エンドポイント名に「機能」ではなく「情報（名詞）」を使うことです。よくある間違いとして /calculateTotal のような「動詞＋処理名」のエンドポイントを作ってしまうケースがありますが、正しくは /expenses という情報の集合に対して GET などのHTTPメソッドで操作を表現します。動詞は情報の外側（メソッド）に置く、と覚えておきましょう。

RESTという考え方は、2000年にロイ・フィールディングという人が書いた博士論文で提唱されました。彼はWebの標準規格であるHTTPの仕様策定にも関わった人物です。「Webがこれだけ大規模に、壊れずに拡張し続けられているのはなぜか」を突き詰めた結果、生まれた設計思想がRESTでした。つまりRESTは、机上の理論ではなく「実際にうまくいっている巨大システム（Web）を観察して言語化したもの」なのです。今皆さんが使っているAPI設計の作法は、Web全体の成功パターンを取り出したものだと思うと、少し見方が変わりませんか。

🗣️ 要約

• 自分たちの情報モデルに対するRESTfulなエンドポイント名の提案、エンドポイント名に動詞を入れない理由、ネストしたリソースの設計方法などをAIに質問できる

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「私たちの情報モデル◯◯に対して、RESTfulなエンドポイント名を提案して」
• 「エンドポイント名に動詞を入れてはいけないのはなぜ？」
• 「実務ではネストしたリソース（例：/users/:id/expenses）をどう設計するの？」

🗣️ 要約

• Day2の資料をもとに、開発テーマの主要な情報モデルについてapiaryでRESTful APIモックを定義し、JavaScriptから呼び出して確認する演習

🗣️ 要約

• 課題は、開発テーマの主要な情報モデル（1〜2個）についてapiaryでRESTful APIモックを定義し、JavaScriptから呼び出して結果を確認すること

Day2で作成した「情報モデル一覧」「状態遷移図」「機能一覧」をもとに、開発テーマの主要な情報モデル（1〜2個）についてapiaryでRESTful APIモックを定義し、JavaScriptから呼び出して結果が返ってくることを確認してください。

🗣️ 要約

• 動作するAPIモック（apiary）と、JavaScriptから呼び出して結果を表示するスクリプトまたは画面

• 動作するAPIモック（apiary）
• JavaScriptから呼び出して結果を表示する簡単なスクリプトまたは画面

🗣️ 要約

• 迷ったら「一覧表示（GET）」から始めるのが最もシンプル
• エラーメッセージをそのままAIに伝えると原因と直し方を教えてもらえる
• チームで手分けする場合は情報モデルごとに担当を分けると進めやすい

• どのエンドポイントから作ればよいか迷ったら、まずは「一覧表示（GET）」から始めてみてください。一番シンプルで、動作確認がしやすい操作です
• エラーが出たら、エラーメッセージをそのままコピーしてAIに「〜というエラーが出た」と伝えると、原因と直し方を教えてもらえます
• チームで手分けする場合は、1人が情報モデルごとにエンドポイントを担当すると進めやすいです

🗣️ 要約

• 情報モデルの状態遷移が、そのままAPIの設計図になる
• エンドポイント名には情報（名詞）、操作にはHTTPメソッド（動詞）を使う
• 実装したAPIは、午後のセッション6でUIと接続する土台になる

今回学んだことを一言でまとめると、「情報モデルの状態遷移が、そのままAPIの設計図になる」ということです。エンドポイント名には情報（名詞）を、操作にはHTTPメソッド（動詞）を使う、という原則を覚えておいてください。

次回は、この後に確認テストを行い、Day1〜Day3の理解度を振り返ります。今日ここで実装したAPIは、午後のセッション6でUI（プレゼンテーション）と接続する土台になるので、動く状態のまま残しておきましょう。

🗣️ 要約

• 情報モデルの状態遷移からRESTful APIのエンドポイントをどう作ればよいか
• エンドポイント名に「機能」を使ってしまっている例をどう直すか

以下の問いに答えられるか確認してみましょう：

• 情報モデルの状態遷移から、RESTful APIのエンドポイントをどう作ればよいか説明できますか？
• エンドポイント名に「機能」を使ってしまっている例を見つけたら、どう直しますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

🗣️ 要約

• 参考リンクはなく、発展課題はエラー時のレスポンス（400番台・500番台）も定義すること

• 参考リンク: なし（社内演習のためチームで作成したapiary定義を参照）
• 発展課題: 余裕があるチームは、エラー時のレスポンス（400番台・500番台のステータスコード）も定義してみましょう

🗣️ 要約

• 受講者からよく出る質問への回答例と、つまずきやすいポイントへの対処法をまとめている

このセクションは、受講者が理解を深めることをサポートする参考情報です。

🗣️ 要約

• 情報モデルが複数ある場合は、まず1つに絞って一通り動かし、その後で横展開する
• 検索のような状態遷移図にない操作は、一覧表示にクエリパラメータを付けたものとして表現できる

🗣️ 要約

• エンドポイント名に動詞（/getExpensesなど）を使ってしまいやすい
• 状態遷移図の粒度が細かすぎて、エンドポイントが増えすぎることがある