一本のAPIを通して、「全体を見て実装する」を学んだ2週間
はじめに
こんにちは！福岡工業大学情報工学部3年 梶原 己大朗です。2026年8月17日から2週間、ディップ株式会社のインターンに参加し、認証基盤のバックエンドAPIの設計・実装を担当しました。
この記事は、その中で取り組んだこと・気づいたことをまとめた参加記事です。技術的にはKotlin／クリーンアーキテクチャでのバックエンド開発がメインですが、私が一番学んだのは「一本のAPIを、プロジェクト全体の中でどう位置づけて実装するか」という視点でした。
インターンの目標
初日に、自分の理想のエンジニア像を言語化しました。
> 全体を見ることができ、その上で自分がどう動くと全体が良い方向へ行くかが分かるエンジニアになりたい。
この考えの背景には、過去のチーム開発でフロント担当として悩んでいた機能が、バックエンドの人に聞いたら簡単に実現できるものだった、という経験があります。自分の担当範囲の外を知らないと、自分の動き方すら決められないと痛感しました。認識のズレやコンテキストの欠落をなくすことが、良いものづくりに直結すると考えています。
このVISIONを踏まえて、今回のインターンでは次を目標に置きました。
> 担当APIの実装を通して、それがプロジェクトに与える意味を把握しながら、適切な設計・実装を行えるようになる。
「機能を作る」ではなく「このプロジェクトのためにこのAPIを作る」ことを目標にする、という区別を意識し続けた2週間でした。
取り組んだこと
なぜこのAPIが必要なのかを理解する
実装に入る前に意識したのは、担当するAPIが「なぜ必要とされているのか」を自分の言葉で説明できる状態を作ることでした。目の前のタスクだけを見ていると「言われたものを作る」で終わってしまいますが、そのAPIがプロジェクト全体のどんな課題を解くために存在するのかを掴めると、設計時の判断基準が自分の中に生まれます。
実際、実装を進める中で「この機能は、既存の仕組みではカバーされていない領域を埋めるために必要」という位置づけを理解できたことが、後半の設計判断すべての土台になりました。
クリーンアーキテクチャで層ごとに実装する
実装はドメイン層 → インフラ層 → ユースケース層 → プレゼンテーション層と、クリーンアーキテクチャの各層を順に進めました。各層で「その層は何に関心を持ち、何に関心を持たないか」を意識したのが今回の肝でした。
特に印象に残っている設計判断を3つ挙げます（内容は一般化しています）。
1. 1つのルールを複数の層で「分担所有」する
ある入力値の検証を、ドメイン層ではあえて書かない構成にしました。その具体的な検証を外部のマネージドサービス（インフラ層）が担保していたためです。ここで「ドメイン層がインフラ層に依存していて、クリーンアーキテクチャが崩れているのでは？」という疑問を持ちました。
壁打ちを重ねて出した結論は、ドメインがインフラに依存している」のではなく「1つのビジネスルールを、ドメインとインフラで意図的に分担所有しているというものでした。ドメインが本当に持つべきルールは「入力が外部プロバイダのポリシーに受理されなければならない」という安定した抽象で、具体的な検証をどこに置くかは設計判断です。前者ならアーキテクチャ違反ですが、後者は完全性を少し犠牲にした意図的な設計だ、と整理できました。「ルールが変われば実装が変わる」ことと「依存している」ことは別物だ、という気づきです。
２. 型でアーキテクチャを守る
ユースケース層では、入力の識別子を生の String からドメインの値オブジェクト（VO）へ変更しました。生Stringのままだと「特定の外部サービスの識別子形式」という前提に気づかれないまま渡ってしまい、ユースケース層が知らないはずのインフラの都合に依存してしまう。VOで受ければ妥当性検証は層の境界で済み、インフラ実装が変わっても壊れません。型設計でクリーンアーキテクチャを守れることを学びました。
セッションとトークンの縦方向の理解
プレゼンテーション層では、セッション破棄の扱いに疑問を持ちました。一部の失効処理をユースケース層で、現在のセッション破棄をプレゼンテーション層で行っている理由です。
深掘りした結果、セッション復活を防ぐ道具がプレゼンテーション層からしか触れないためだと分かりました。プレゼンテーション層は「HTTP・セッション・Cookieといったプロトコル固有の関心事なら、業務処理に近いものでも引き受ける層」でもあるのだ、と理解できました。
さらに掘り下げると、なぜ認証方式が複数併存しているのかは、「このAPIが誰から呼ばれるか」に行き着きました。担当したAPIは、複数のサービスから利用される入口を経由して呼び出される設計になっており、呼び出し元の性質（同じドメインのブラウザから直接来るのか、別サービスを経由して来るのか）が根本的に違うため、それぞれに最適な認証方式が割り当てられていたのです。ここは、担当APIの中で「他のサービスとの繋がり」に触れる部分でした。
私にとってこの気づきは大きなものでした。ドメイン層やインフラ層の実装は「担当APIの内側」に閉じた話ですが、プレゼンテーション層まで来て初めて、担当APIがシステム全体のどこに位置づくのか——上流にどんなサービスがあり、どういう経路で自分のAPIに届くのか——という縦方向の全体像が見えました。「全体を見て、その中で自分がどう動くかを分かるエンジニアになりたい」という当初のVISIONに、一本のAPIの実装からここまで近づけたのは、想像以上の収穫でした。
気づき・学び
・横方向と縦方向の両方で理解を広げる。 関連機能に関心を広げるのが横方向、「誰から・どう呼ばれるのか」を辿るのが縦方向。両方があって初めて、一段俯瞰した提案や意思決定ができるようになると学びました。
・トレードオフは抱え込まず相談する。 ツール導入の範囲や、エラーの扱いなど、判断が割れる場面ではメリット・デメリットをPRに書き出し、方針をすり合わせました。見る人（未来の自分を含む）に「なぜそう考えたか」を残すことが大切だと感じました。
・設計理由はドキュメントに残す。 「なぜこの技術を選んだか」「なぜこのAPIが必要か」がドキュメントに残っていたおかげで、後から理由に辿り着けました。コメントやPR文の分かりやすさも含め、意図を残すことの重要さを実感しました。
・できるようになったことを、抽象化して強みに変える。 「このAPIがどこから呼ばれるか分かった」で止めず、「サービスの使われ方を意識し、それを踏まえた設計ができるようになった」と一般化する。他のプロジェクトでも通用する形に落とし込むことを教わりました。
結果
目標だった「APIの実装を、プロジェクトに与える意味を把握しながら設計・実装する」は達成できたと感じています。ドメイン層からプレゼンテーション層までを一通り実装し、各層の責務を意識した設計判断を自分の言葉で説明できるようになりました。
初日は「クリーンアーキテクチャに沿った開発をこれまでできていなかった」という状態でしたが、最終的には、層の境界を意識しながらコードを読み、ロジックの破綻に気づけるところまで来られました。何より、目の前の機能を「プロジェクトという全体の中の一部」として捉えて必要な実装を理解できるようになったことが、当初のVISIONに一歩近づけた実感につながっています。
おわりに
2週間という短い期間でしたが、技術的な知見だけでなく、「実務でどう考えて実装・報告・質問をするか」を濃く学べました。特に、日々の日報に対して具体的なフィードバックをいただけたことで、自分の成長を言語化し、次の行動に落とし込む習慣が身につきました。
一方で改善したい点もあります。振り返ると、自分の説明は「自分がどう考えたか」を軸にしがちで、相手に応じて情報の粒度や方向性を調整することがまだできていませんでした。また、「できるようになったこと」を具体的な事実のまま止めてしまい、他のプロジェクトでも通用する強みの形にまで抽象化しきれていない場面がありました。自分の作業を構造化して理解したうえで、相手に伝わる形に一般化する力は、これから磨いていきたいです。
エンジニアリングの技術はどのインターンでも学べると思いますが、一本のAPIを通して事業全体との関わりまで見渡す視点を鍛えられるのは、このインターンならではだと思います。機会があればぜひ挑戦してみてください！
