はじめに はじめまして。2025年4月に新卒でニフティに入社した宮村です。 ニフティのエンジニア職には On-the-Job Training（OJT） という制度があり、私が入社した年度では入社後の約1年間で 3つの異なるチーム を経験しました。各期約3ヶ月、実際の業務に携わりながら技術とチームワークを学んでいく仕組みです。 この記事では、私がOJTで経験した3つのチームでの業務内容や、やりがい・苦労した点をエピソードベースでお伝えします。 「ニフティのOJTって実際どんな感じなの？」 という疑問を持つ方に、少しでもリアルな雰囲気が伝われば嬉しいです。 OJTの前に：新人研修（4月〜6月） OJTが始まる前に、約2ヶ月間の 新人研修 があります。研修は大きく3つのフェーズに分かれています。 共通研修（4月） まずはビジネス職と合同の共通研修からスタートします。社会人としての基礎やニフティの事業について学ぶ期間です。職種を問わず同期全員で受けるため、エンジニア以外の同期とも関係を築ける貴重な機会でした。 技術研修（5月） エンジニア職のみの技術研修に移ります。外部の研修会社による講義形式で、Web開発の基礎を体系的に学びます。HTML/CSS/JavaScriptといったフロントエンドの基礎から、Linuxやサーバの基本、バックエンド技術、コンテナ、テスト手法まで幅広くカバーされます。プログラミング経験の差に関わらず、全員が同じスタートラインに立てるよう設計されていました。 エンジニア定例（6月頭） 最後に、 社内のエンジニアが講師を務める研修 （エンジニア定例）を受けます。Git基礎、AWS基礎、生成AIなど、ニフティの現場で実際に使われている技術や手法を先輩エンジニアから直接学べます。外部研修で得た基礎知識を、ニフティの実務にどう活かすかという視点で深掘りしていく内容で、OJTに入る前の総仕上げとなりました。 OJTの基本的な流れ 各期の流れはおおむね共通しています。 目標設定 — 配属後、トレーナーや上長と面談し、その期で達成したい目標を決めます 開発業務 — スクラムなどの開発手法を通じて、実際のプロダクト開発に参加します 振り返り — 期の終わりに目標の達成度を振り返り、次期への引き継ぎを行います トレーナーの方が日々の相談相手としてついてくださるので、困ったときにすぐ聞ける環境が整っています。 一期：SSOチーム（6/12〜9/20） チームについて サービスインフラチームの うさかぴサブチーム に配属されました。名前から想像し辛いかもしれませんが、ニフティ全体で使われている認証・認可システム 「SSO」 やその他ユーザー管理に使用されるシステム を開発・運用するチームです。 SSOは全社共通の基盤であり、止まるとニフティの多くのサービスに影響が出ます。そのため、変更には慎重さが求められる環境でした。 使用技術 OpenID Connect（OIDC） Python（Django） AWS 主な業務内容 SSOをOIDCの標準仕様に近づける改修 @nifty 優待サービスの販路拡大に向けた改修 新規サービスにOIDC導入するための改修 やりがい 最もやりがいを感じたのは、 SSOをOpenID Connect（OIDC）の標準仕様に近づける改修 を行えたことです。 実は大学時代にOIDCを活用した研究をしていたため、この分野には馴染みがありました。スプリントのプランニングで標準化の方針が検討されていた際、開発を進める中で「この修正だけでは足りない箇所がある」ことに気づき、自ら追加の修正を提案・実装しました。 結果として、OIDCのライブラリを導入するだけでSSOを使えるようになり、プロダクトの利便性向上に貢献できました。 学生時代に学んだことが実務で活きた瞬間 は本当に嬉しかったです。 苦労した点 一方で、初めての配属ということもあり、 実務の開発プロセスを一から習得する 必要がありました。スクラム、テストコードの書き方、本番環境を止めずに品質を担保するための工夫など、学生時代には経験のなかったことばかりで最初は苦戦しました。 また、障害対応の場面に立ち会った際に自分の無力さを痛感したこともあります。当時は「一人で解決しなければ」という意識が強く、難しいタスクを抱え込みすぎてしまうこともありました。これは後の期で大きな学びに繋がります。 二期：ポータルチーム（9/21〜12/20） チームについて 第一開発チームの @niftyトップページを担当するサブチームに配属されました。 @niftyトップページ の開発・運用に加え、新規事業の開発も手がけるチームです。 サービスの企画担当者と密にコミュニケーションを取りながら進めるスタイルで、AWSをはじめとしたモダンな技術スタックを使った開発が特徴です。スクラム開発（2週間スプリント）を採用し、デイリースクラムでチーム全体の進捗を共有していました。 使用技術 microCMS Next.js AWS（Terraform） 主な業務内容 「@niftyトップページ」の開発・運用 新規事業のAWSインフラおよびフロントエンドの構築 やりがい・苦労した点 この期で最もやりがいと苦労を感じたのは、 未経験の状態からAWS環境の構築にゼロから挑戦したこと です。 当初はフロントエンド寄りの業務を想定していましたが、チームの状況や自分自身の希望もあり Terraform未経験の状態からインフラ構築 を任されることになりました。正直、最初は不安もありましたが、これが結果的に大きな成長のきっかけになります。 先輩方が過去に構築した環境を参考にしながら、VPC・DNS・CI/CDパイプラインの作成を進めました。ただ、今回の要件と過去の構成には差分があり、初めて触る技術の中でその差分を埋める作業には非常に苦労しました。 一期での反省を活かし、 困ったときは一人で抱え込まず、積極的にチームへ相談する ことを意識しました。先輩方の手厚いフォローのおかげで、最終的には新規事業のフロントエンドインフラをほぼ一人で構築し、動作確認まで完了できました。 また、一期でSSO（認証）の経験があったことが二期で活き、新規事業のSSO導入時に的確な助言ができたことも印象に残っています。 異なるチームでの経験が繋がる瞬間 は、OJTならではだと感じました。 三期：金剛チーム（12/21〜3/20） チームについて 入会システムチームの 金剛サブチーム に配属されました。代理店様が光回線やオプションサービスの入会に使用するシステムの、開発・運用を担当しています。 代理店様との接点が多く、社内外の複数部署との連携が求められる環境です。 使用技術 PHP（CakePHP） AWS（Terraform） 主な業務内容 「@nifty つなぎモバイル」をより多くの方に申し込めるよう、獲得代理店様向けの申込ツールを改修 サインアップシステムにクレカチェック機能を追加 光コラボ入会時のオプションサービス申し込みフォームのデザイン刷新 「ニフティ会員特別でんきプラン」申し込みシステムのAWS移行（Terraform） やりがい・苦労した点 三期では 複数のプロダクトを横断して改修する という、これまでにない経験をしました。 中でもオプションサービス申し込みフォームのデザイン刷新は、サービスの企画や制作を行うチーム、光コラボ申し込みシステムのチーム等と連携しながら進行するプロジェクトで、初めて経験する 多方面とのマルチパスな調整 に難しさを感じました。ただ、一期・二期で培った「相談すること」「周囲を巻き込むこと」の大切さを実践できている手応えがあります。 また、でんきシステムのAWS移行では、一期のAWS経験と二期のTerraform経験がそのまま活きました。OJTを通じて積み上げてきた技術が 三期で統合された ように感じ、自分自身の成長を実感できた瞬間でした。 OJT全体を通して 3チームの共通点 スクラム開発 — 三部署ともスクラムを採用しており、一度身につけた開発の型はどのチームでも活きました AIの活用推進 — 一期ではAI推進チームのメンバーがおり、二期ではKiroを使ったspec開発も実施されるなど、各チームで積極的にAIを取り入れています 人の温かさ — どのチームでも、わからないことがあれば時間を割いて丁寧に教えてくださる先輩方ばかりでした 技術の幅の広がり OJTを通じて触れた技術は、期ごとに大きく異なります。 一期 : Python / Django / OIDC 二期 : Next.js / microCMS / Terraform 三期 : PHP / CakePHP / Terraform バックエンド → フロント＋インフラ → レガシー＋モダンの混在環境と、 毎期まったく異なる技術スタックに触れられる のはOJTの大きな魅力です。 一番の成長：「相談する力」 振り返ると、OJTを通じた一番の成長は 技術力よりも「相談する力」 かもしれません。 一期では「一人でやろうとしすぎていた」という反省がありました。二期ではそれを意識的に改善し、積極的にチームへ相談するようにしました。そして三期では、トレーナーから「自走できる」と評価されるまでになりました。 一人で抱え込まないこと は、技術を学ぶことと同じくらい大切なスキルだと実感しています。 こうした成長を実現できたのは、 3つのチームを渡り歩きながら、毎回新しい環境で「相談する」経験を積み重ねられるニフティのOJTだからこそ だと強く感じています。チームが変わるたびに関係構築からやり直す大変さはありますが、その繰り返しこそが「相談する力」を本物にしてくれました。 ニフティに興味を持ってくれた方へ 私が入社した年度では、OJTを通じて約1年間で 3つの異なるチーム を経験しました。毎回新しい環境・新しい技術・新しい人間関係にゼロから飛び込むのは正直大変でしたが、だからこそ 圧倒的に視野が広がり、確かな成長を実感できた 1年間でした。 私が伝えたいことは3つです。 学生時代の経験は活きる場合がある — 私の場合はOIDCの研究経験が一期で即戦力になりました。どんな経験も無駄にはなりません 困ったら相談してほしい — ニフティには優しい先輩方がたくさんいます。一人で抱え込む必要はありません 毎期が新しいチャレンジ — 「できない」が「できる」に変わる瞬間を、OJTでは何度も味わえます この記事が、ニフティに興味を持ってくれた方にとって、少しでも働くイメージを持つきっかけになれば幸いです。

こんにちは。AWS シニアソリューションアーキテクトの崔 祐碩です。首都圏を中心に 125 店舗のスーパーマーケットを展開する サミット株式会社 （以下、サミット）では、DX 推進の一環として AI コーディングアシスタント「 Kiro 」を活用し、情報システム部門が自らの手で業務アプリケーションを素早く形にする取り組みを進めています。本ブログでは、サミット 情報システム部 企画・開発グループの小池様に、Kiro 導入の背景や具体的な活用事例、今後の展望について伺いました。 サミット株式会社について サミット株式会社は、東京・神奈川・埼玉・千葉の 1 都 3 県で 125 店舗を展開するスーパーマーケットチェーンです。1963 年の設立以来、「嘘の無い仕事」を経営理念に掲げ、売上高約 3,488 億円（2025 年 3 月期）、従業員数約 18,000 名の規模で事業を展開しています。「サミットが日本のスーパーマーケットを楽しくする」という事業ビジョンのもと、お客様一人ひとりに寄り添う店舗づくりとリテイル DX の推進に取り組んでいます。 Kiro との出会い ― 「これは運命でした」 DX 推進における課題 ― 「作りたいもの」が形にならない AWS： そうした課題を抱える中で、 Kiro とはどのように出会われたのでしょうか？ 小池様： もともとはコードエディタを使って、チャットボットの画面でコードを書いてはコピー＆ペーストする、というループでコーディングをしていました。他の AI コーディングツールも使っていましたが、当時の生成 AI が読み込めるコンテキスト量と、出力されるコードの品質には限界がありました。 様々な AI コーディングツールが出てきた中で、AWS の担当者からの紹介もあり、 Amazon Q Developer を試していたところ、ちょうど Kiro がリリースされたんです。自然な流れでたどり着いた、まさに運命的な出会いでしたね。 AWS： 他のツールと比較して、Kiro を選ばれた決め手は何でしたか？ 小池様： 開発ツールの選択は好みの問題になりがちですが、企業として使っていく上での条件を考えると、Kiro が最もリスクが少なく安心できるものでした。ポイントは大きく 3 つあります。 シンプルさと展開のしやすさ： Kiro はインストールしてログインすれば、すぐに使い始められます。初期設定の手間が少なく、環境の再現性が高いため、チームへの展開もスムーズです。 ガバナンス： Kiro はログインしないと使えない。これは企業利用において非常に重要です。拡張性が適切に管理されていることも、ガバナンスの観点ではメリットになります。何でもできてしまう環境は、統制が効かなくなるリスクがあります。 クラウドとの統合： AWS のバックエンドと統合したプロダクトを作ることを考えると、Kiroを使っておけば開発環境からクラウドまで一貫した体験が得られるという安心感があります。 つまり、「王道」のやり方ができるツールだと感じました。スタンダードで、シンプルで、ガバナンスが効く。企業の情報システム部門が安心して採用できるツールだと思います。 Kiro で作ったもの 事例 ① ：店舗クラスター分析ダッシュボード ― 12 時間で PoC を実現 AWS： 具体的に Kiro で開発されたものを教えてください。 小池様： 最初の事例は、リテイル DX チームからの依頼で作った店舗データの分析ダッシュボードです。店舗の従業員に対して、クラスター分析の結果を可視化して見せたい、PoC をやってみたいという要望がありました。 当初はBIツールなどを導入する話もありましたが、PoCの段階では新たなツールの導入には時間とコストがかかります。費用対効果が見えない中での意思決定にも時間を要するため、まずは自分の手で素早く形にしてみようと考えました。 AWS： 実際にどのくらいの時間で完成したのでしょうか？ 小池様： 初期バージョンは約 12 時間で完成しました。HTML ベースで Excel データを読み込んで表示するダッシュボードです。Kiro の Spec-driven Development の機能を活用して、要件から設計、実装までを一気に進めました。 店舗データ分析 BI ツール AWS： DX チームの反応はいかがでしたか？ フィードバックからすぐ改善 小池様： 「こんなにすぐできたの？」という驚きの声がありましたね。フィードバックを受けて修正する作業も、5 時間程度で何回かのイテレーションを回せました。しかも、別の打ち合わせをしながら、Kiro にプロンプトを投げて結果を待つ間に会議に参加する、という並行作業ができたんです。 フィードバックの内容も、機能を減らしたいとか、表示するタブやグラフの切り替え、初期データの自動読み込みといった調整レベルのもので、設定の切り替えで対応できるものがほとんどでした。 AWS： 従来のアプローチだと、同等のものを作るのにどのくらいかかると見積もられますか？ 小池様： 通常、このような PoC を外部に依頼する場合、要件定義からパートナーとの契約、見積もり、稟議、発注というプロセスだけで 1〜2 か月はかかります。開発自体も 1〜2 人月程度は見込まれ、全体では少なくとも 3 か月、費用も数百万円単位になることが一般的です。それが Kiro を使うことで、一人の担当者が 12 時間 + フィードバック対応 5 時間で実現できたというのは、非常に大きなインパクトです。 事例 ② ：3D インタラクティブプレゼンテーション ― 外部発表資料を 1 日で AWS： 他にも Kiro で作られたものはありますか？ 小池様： Vibe コーディングの事例を外部に発表する機会がありました。外部への発表ですから、それなりにクオリティの高い資料が求められる場です。 最初は HTML ベースで資料を作り始めたのですが、途中で「せっかくなら 3D 効果を入れてみよう」と思い立ち、Three.js を使った 3D インタラクティブなプレゼンテーションに仕上げました。聴衆が自由に 3D 空間を動き回れるよ うな体験型の資料です。 AWS： 制作時間はどのくらいでしたか？ 小池様： 他の作業と並行しながらも、約 8 時間で完成しました。3D 効果を入れずにシンプルなスライドにするなら 1〜2 時間で終わったと思いますが、外部発表の場ということもあり、表現にこだわりました。 3Dバーチャル展示会を回遊しながら楽しむプレゼンテーション 通常、外部向けの発表資料は、構成の検討からデザインの調整まで含めると 1 週間程度かかることも珍しくありません。それが Kiro を活用することで 1 日で完成し、さらに 3D インタラクティブという新しい表現も実現できました。 この経験から、社内の部会資料や共有資料も HTML ベースで作れるようになるといいなと考えています。議事録やメモをマークダウンで書いて、Kiro でスライド化する。そういう文化が社内に根付けば、資料作成の負担は大幅に減る はずです。社内の便利ツールとしても展開していきたいですね。 事例 ③ ：店舗エリア分析マップ ― 国土地理院 API を活用した地図アプリ AWS： 最後にもう一つ、事例をご紹介いただけますか。 小池様： マーケティング業務で使う地図ベースのエリア分析ツールを Kiro で作りました。店舗番号を入力すると、国土地理院の API から市区町村のデータを取得して、対象エリアを地図上に可視化するものです。 例えば、特定のエリアに何人住んでいるのか、商圏の人口分布はどうなっているのか、といったことを視覚的に確認できます。 AWS： こちらの制作時間は？ 小池様： これも 12 時間未満ですね。もともとコードエディタでベースを作っていたものを Kiro で作り直したのですが、モデルも良くなっているので、かなり実用的なものに仕上がりました。外部 API との連携や地図の描画処理など、自分でゼロから調べてコーディングしようとすると相当な時間がかかる部分を、Kiro が一気にやってくれます。 店舗エリア分析マップ これからの夢 ― リバースエンジニアリングと、パートナーとの新しい協業 AWS： 今後、Kiro を使ってどのようなことに取り組みたいとお考えですか？ ① レガシーシステムのリバースエンジニアリングと刷新 小池様： 一番やりたいのは、レガシーシステムのリバースエンジニアリングです。 多くの企業で、過去に作られたシステムが「なぜ動いているか分からない」状態で残っていると思います。担当者が変わり、ドキュメントも残っていない。コードだけが正しい、という状況です。 Kiro を使えば、既存のコードからドキュメントを自動生成できます。実際に私はすでにこれを始めていて、コードを Kiro に読み込ませてリバースエンジニアリングでドキュメントを作らせています。 AWS： そこから先の展望も見えてきますね。 小池様： はい。まず、今まで見える化すらできなかったレガシーコードの中身が、ドキュメントとして可視化される。これだけでも大きな一歩です。そして、そのドキュメントをチームでレビューして内容を正しく整理したら、今度はそれをスペック（要件定義）として Kiro に渡して、要件に合った新しいシステムを AI で作り直す。 つまり、古いコード → ドキュメント化 → スペック整理 → 新規開発 という流れです。 今までは、このドキュメント化の工程自体が膨大な手作業で、現実的に手が付けられなかった。それが Kiro によって一気に可能になる。ドキュメントさえできれば、そこからメンテナンスもしやすくなりますし、新しいメンバーへの引き継ぎも格段に楽になります。 ② パートナーとの協業を「動くもの中心」に変える 小池様： もう一つの夢は、パートナーとの協業モデルを根本的に変えることです。 実は一部の案件で、Kiro で実際に動くモックアップ ― 単なる画面イメージではなく、実データを読み込んで画面遷移も動作もするレベルのもの ― を作って開発パートナーに渡すという試みを始めています。パートナーがその意図を正しく理解できた場合は、こちらの期待の 120% のものが返ってくることもあり、手応えを感じています。 これを全面的に展開していきたい。Kiro は Spec-driven Development なので、モックアップを作る過程で仕様書（ Spec ）も自動的に生成されます。つまり、動くモックアップと仕様書をセットでパートナーに渡せる。パートナーはコードと仕様書の両方を参照しながら本番実装を進め、レビュー会では動くものを見ながらその場で修正する。1〜2 回のイテレーションで最終版に近づけて、完成後はレビューを通じて更新された仕様書に加え、運用ドキュメントなども Kiro で追加生成する。 Kiro を活用した新しいアプローチ 従来はドキュメントだけが共通言語でしたが、新しいアプローチでは動くコードと Kiro が生成した仕様書の両方が共通言語になる。要件定義をドキュメントから始めるのではなく、動くものと仕様書を同時に作り、開発・レビューを経てドキュメントも一緒に育てていく。日本の IT 業界に根付いたウォーターフォール文化を、もう少しアジャイルに変えていけるのではないかと思っています。 Kiro を使うコツ ― セッション管理とステアリング AWS： Kiro を効果的に使うためのコツがあれば教えてください。 小池様： 一番大事なのは、セッション情報の管理です。AI コーディングツール全般に言えることですが、長時間の開発ではコンテキストの引き継ぎが重要になります。Kiro ではこれを効率的に管理する仕組みがあり、私はそれを積極的に活用しています。 私はプロジェクトごとにセッション情報を記録するルールを設けていて、Kiro に「このタイミングでセッション情報を保存して」と指示しています。再開時には、最新のセッション情報とプロジェクトメモリーを参照するようにルールで定義しています。 もう一つのポイントは、 Steering  の活用です。ステアリングには、プロジェクトごとの統制ルールや、セッション再開時に参照すべき情報、コーディング規約などを定義しています。例えば「セッション再開時はプロジェクトごとの最新セッション情報とプロジェクトメモリーを必ず参照すること」といったルールです。 さらに、Steering の内容自体も Kiro との対話を通じて作成できます。「こういうルールをステアリングに追加して」と指示すると、Kiro が内容を整理して記録してくれるため、開発環境の設定も対話の中で完結します。 今後の展望 AWS： 最後に、今後についてお聞かせください。 小池様： 私は Kiro を活用した AI 開発によって、コードの品質向上や開発スピードの改善を実感しています。この流れをチーム全体に広げていきたいと考えています。 そのためにも、Kiro が Web 経由でクラウド環境から利用できるようになることや、AWS のサービスとの連携がより深まっていくことに期待しています。ローカル PC への環境構築が不要になれば、開発経験が浅いメンバーでもすぐに使い始められます。チーム全員が統一された環境で AI 支援を受けながら開発できるようになれば、社内での活用をさらに拡大していけると考えています。 著者について 小池 朋昭（こいけ ともあき）の紹介 サミット株式会社 情報システム部にて、ハイブリッドクラウド化やレガシー刷新をPM／テックリードとして推進。データスチュワードとして全社データの活用基盤整備も主導。現在はVibe コーディングによる内製開発やアジャイル 開発体制の構築に取り組み、業務・IT・データを横断した全社DXを牽引している。 崔 祐碩 （Woosuk Choi）は AWS Japan Senior Solution Architect としてエンタープライズ・商社のお客様を担当し、データ分析基盤やプライベートクラウドの構築、DevOps/SREの運用経験を活かして、クラウド導入やData/AIソリューションの実装を支援しています。

エピソード紹介 Ep.1 – クリーンアーキテクチャとは ← 今回はこちら Ep.2 – 認証方式の実践的な紹介 Ep.3 – ER設計と監査ログ Ep.4 – RepoScanner の実装とテスト Ep.5 – Copilot プロンプトを効率化 こんな方へ特におすすめ クリーンアーキテクチャが何かイメージを掴みたい方 概要 こんにちは。サイオステクノロジーのはらちゃんです！ フロントエンドを開発していたとき、アトミックデザインという手法を知りました。ざっくり言うと小さな部品を用意して、使いまわせるようにする設計です。 バックエンドを開発するときに、同じような設計手法があるはずだと気になりました。 そこで知った手法こそ、クリーンアーキテクチャです。 — 本シリーズでは、Copilotを活用しつつ、クリーンアーキテクチャに沿って小規模なプロダクト「RepoScanner」を設計・実装した経緯をまとめます。 シリーズの前提知識として、このエピソードでは、クリーンアーキテクチャの基本を簡潔に説明します。 定義 はじめに、どのような方針であるのかイメージを掴みましょう。 クリーンアーキテクチャは、ソフトウェアを複数の関心ごとに分離し、変更に強くテストしやすい構造を保つ設計原則です。中心にビジネスルールとなるドメインを置き、外側にインフラやUIを置くことで、依存の向きを守ります。 クリーンアーキテクチャの解説でよくみられるイラストです。 主なレイヤー 全体は以下のような層に分かれています。 src/ ├── domain/ # 【最内部】ビジネスルール │ ├── entities/ # ここにエンティティを置く │ └── repositories/ # リポジトリインターフェースを定義する ├── use-cases/ # 【内側】アプリケーション固有の手順 │ └── createUser.ts # ユースケースの実装をする ├── infrastructure/ # 【外側】技術固有の実装 │ └── persistence/ # 永続化の実装をする └── functions/ # 【最外部】エントリポイント └── http/ # ここで依存性注入を行う 具体的にどのような役割なのか見ていきましょう。 Domain Domain層は、「コードでビジネスを記述する」場所であり、技術的な詳細（データベースやWebフレームワーク）とは無関係に、ビジネスの正解を定義する最も重要な層です。 エンティティ（概念） 「何ができるか」の定義。型やNullを許容するかなどのビジネスルールを持つ。 具体的には、以下のような定義をします。ここではユーザー情報を用意しています。 Python @dataclass(slots=True) class User: user_id: UUID display_name: str | None created_at: datetime last_login_at: datetime | None リポジトリ（ふるまい） 「どのように取得 / 保存するか」の定義。エンティティの操作を抽象化する。 具体的には、以下のような定義をします。 定義したエンティティを用いて、「ログイン時に得られた情報を元に、ユーザーを作成 / 更新し、結果として User エンティティを返す」という処理をしています。 リポジトリのメソッド引数で再び型を明記することで、Pythonの型ヒントを機能させる意味もあります。 Python class UserRepository(Protocol): def upsert_login_user(self, display_name: str | None) -> User: ... Use Cases Use Cases層は、どのようにエンティティやリポジトリを組み合わせて業務フローにするかを表現する層です。 司令塔としての役割があり、受け取った入力に対しリポジトリを使ってデータを取得 / 更新します。 例えば、以下のような具体的な機能を実現しています。 トークンでユーザー情報を取得して情報を更新する DBから項目を受け取ってデータを返す Infrastructure Infrastructure層は、Use Cases層とさらに外側の層を繋ぐための層です。 データの変換と橋渡しを行う、アダプターという役割を担って外部ライブラリやDB を利用します。 例えば、以下のようにデータの相互変換や外側への具体的なアクセス実装をしています。 db.py ファイルでSQL に接続する SQL文で操作を指定する functions Functions層はビジネスルールを組み合わせ、外側から受け取ったリクエストを処理する層です。 これにより、UIの変更（HTML→JSON）や、データベースの変更（MySQL→PostgreSQL）が、Domain層に一切影響を与えないように保護しつつ、具体的な技術要素との連携を実現しています。 例えば、以下のような具体的な機能を実現をしています。 HTTP API のスキーマを定義する main.py ファイルでエントリポイントの指定をする Pydantic を利用してバリテーションをする 依存性ルール（外側→内側） コードの依存は常に外側から内側へ向かいます。内側の層が外側の具体実装を import してはいけません。 依存性逆転の原則に従い、ドメインやユースケースがインターフェースを定義し、インフラがそれを実装します。 functions（最外部） -> infrastructure（外側実装） -> use-cases（アプリ手順） -> domain（最内部ルール） 依存を分けるメリット 大きく2つ考えられます。 影響範囲が狭い ドメイン / ユースケースを外部変更から隔離でき、要件変更など対応しやすい。 依存性注入（DI）とテスト ユースケースはリポジトリなど依存をコンストラクタやファクトリで注入して受け取る。 テストではその注入ポイントにモックやインメモリ実装を差し替えることで、ユースケース単体で即テストできる。 依存を分けるデメリット こちらも、大きく2つ考えられます。 初期コスト インターフェース定義やDIの仕組み、アダプター実装が増える。 実装の一貫性維持 境界のインターフェース設計を誤ると、後続実装で整合性を保つのが難しい。 層をまたぐ設計と抽象が増え、設計理解の学習コストが上がる。 三層構造との違い ここまで学んで、依存を分けるなら三層構造でもやっていなかったか？と疑問に思いました。 クリーンアーキテクチャと三層構造は、どちらもソフトウェアの「関心事を分離する」ための設計手法ですが、最大の違いは「依存関係の方向」と「システムにおいて何を中心と捉えるか」にあります。 三層構造は、システムを役割ごとに「上から下へ」3つの層に分けるアーキテクチャです。 プレゼンテーション層 ビジネスロジック層 データアクセス層 ここでは、プレゼンテーション層はビジネスロジック層に依存し、ビジネスロジック層はデータアクセス層に依存します。つまり、システムの中心がデータベースになることが多いです。 システムの中心がビジネスロジックであるクリーンアーキテクチャとは依存関係の方向が違うことがわかりました。 まとめ 今回は、クリーンアーキテクチャとは何かをご紹介しました。 依存は外側→内側。インフラ実装を内側に漏らさない。 エンティティは何ができるか、リポジトリはどのようにするか。 DI を使えばユースケースはテストしやすくなる。 ユースケース単体と境界・統合を優先して整備する。 これからクリーンアーキテクチャの思想に則った設計を行うのでお楽しみに！ 参考 The Clean Architecture ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Copilot × Clean Architecture | クリーンアーキテクチャとは first appeared on SIOS Tech Lab .