はじめに
こんにちは、福岡工業大学情報工学部3年の和泉瑠生です。
私は2026年8月31日から1週間、ディップ株式会社のCTO直属プロジェクトのインターンシップに参加しました。担当したのは、将来的に会社全体での展開を見据えた新規の「JIT（Just-In-Time）アクセス管理基盤」の初期開発です。
この記事では、インターン中に取り組んだことと、そこから得た学びを紹介します。
インターンの目標
私は普段からAIを活用して実装をしているのですが、デスクの周りの社員の方がClaudeを9つのターミナルで動かし、設計、実装、レビューを並列で進めている姿を見て、プロのAI活用ノウハウを身につけたいと思いました。
そこで、次の3つを目標にしました。
- 複数のAIを並列で使い、設計から実装まで効率的に進める
- AIに任せきりにせず、最終的な意思決定とその記録に自分で責任を持つ
- CTOのレビューを通したADR（重要な設計判断の記録）を3〜5件、チームのレビューを経たPR（コード変更のレビュー依頼）を30〜50件作成することを目指す
これらは、私が掲げる「作る側と運営する側の両方の視点を活かし、自ら課題を解決しながら、チームが最大限のパフォーマンスを発揮できる環境を作る」というVISIONに近づくための具体的な挑戦です。
このVISIONの原点には、ハッカソンやイベントを主催し、自分が動いたことで参加者が喜んだり、楽しんだりしてくれた経験があります。その経験から、自分の実装だけで要件を満たすのではなく、他部署とのコミュニケーションロスを減らし、チームの力を引き出すことで、ユーザーに最短でプロダクトを届けられるエンジニアを目指しています。
取り組んだこと
ゼロから開発したJITアクセス管理基盤
企業が扱うDBには、個人情報や要配慮個人情報など、限られた人だけが扱うべき情報が保存されています。業務や障害対応のために閲覧が必要な場面がある一方、あらかじめ多くの人へ常時アクセス権を付与すると、情報漏えいや内部不正のリスクが高まります。そのため、必要な人へ、必要な範囲の権限を、必要な時間だけ付与する仕組みが求められます。
そこでゼロから開発したのが、企業のDB情報を確認するユーザーが、閲覧理由と必要な権限を申請し、最大24時間だけ情報を閲覧できる社内基盤です。権限の付与と失効を自動化し、誰が、いつ、なぜ、何を見たのかを記録します。まずは配属プロジェクトで利用し、将来的には会社全体で利用できる共通基盤へ発展させる展望があります。
課題を理解し、完成条件を定める
初日の全社オンボーディングとキックオフ面談では、インターンの目標や将来のエンジニア像を整理しました。その上で、まずは課題の背景と保護対象となるデータを理解し、5日間で何を完成させるかを定めました。
短期間で機能を増やしすぎると、基盤の目的である「アクセス権の最小化」が曖昧になります。そこで、「申請→自動付与→閲覧→失効→監査」という中心の流れをWeb画面上で一周できることに開発範囲を絞りました。
初日には、3か月に1度の全社総会にも参加しました。社長をはじめ、CIO、CTO、常務執行役員の方々や複数の本部長に挨拶する機会をいただき、マグロの解体ショーも初めて見ることができました！開発だけでなく、会社の雰囲気を知る貴重な時間になりました。
最小権限を実現する設計
主な設計判断は、アクセス権ごとに付与日時と有効期限を記録し、データベース側の現在時刻を基準に権限が有効かを判定することです。また、一般個人情報と要配慮個人情報の権限を分け、申請者が必要とする範囲だけ閲覧できるようにしました。
セキュリティに関する判断を個人の記憶だけに頼ると、後から理由を確認できず、実装中に方針がぶれる可能性があります。そのため、採用案だけでなく、不採用案や既知の弱点も、設計判断を共有するドキュメントへその都度記録しました。
AIを役割分担して並列開発する
設計後はCTOの長島さんへ現状を報告し、複数のAIエージェントを並列で動かしました。基本的には中心となる2つのセッションのうち、1つは設計と実装を進める役割、もう1つはターミナル操作の補助や、コードと設計を自分が理解するための役割に分けました。
並列で安全に作業する手順
複数のAIが同じコードを同時に変更すると、作業内容が混ざったり、一方の変更を壊したりする危険があります。そこで、AIごとに独立した作業環境を用意できるworktreeを活用し、「1セッション・1 worktree・1ブランチ」を原則にしました。
各AIは専用のworktreeで作業し、完了後にPR単位でレビューしてから変更を統合しました。また、AIが従うプロジェクト固有の作業ルールをskillsとして用意し、独立した作業環境の作り方、設計判断の残し方、データベース構造を変更するときの確認方法などを、どのAIも同じ手順で実行できるようにしました。
効率的に並列化するためには、単にAIの数を増やすのではなく、着手前にそれぞれの役割と作業範囲を分けることが重要です。複数のAIに関係する設計判断は共通のドキュメントに集約し、異なる前提で実装を進めないようにしました。
この方法で、次の主要機能を1日で実装しました。
- 申請とアクセス権の自動付与
- 権限区分に応じた個人情報の閲覧
- 読み取り専用のデータ検索機能
- 申請、付与、閲覧、拒否、データ検索の監査ログ
- 監査管理者向けの確認画面と事後承認
SQL（データベースを操作するための言語）は読み取り専用とし、実行時間、取得件数、アクセスできるデータの範囲を制限しました。また、開発環境では権限の有効期間を60秒に短縮し、24時間待たずに失効を検証できるようにしました。
役員レビューを改善につなげる
実装した基盤は、まずCTOの長島さんへプレゼンし、フィードバックを基に改修しました。ただし、すべての意見をそのまま実装するのではなく、初期開発の目的と残り時間に照らして採用・不採用を自分で判断し、見送った理由も記録しました。
改修後は、申請から60秒後の自動失効、失効後のアクセス拒否、監査ログまでを実画面で確認しました。あわせて、公開情報と申請が必要な個人情報を分け、画面の導線もデモ向けに整理しました。
その後、CIOの鈴木さんとCTOの長島さんへ最終プレゼンを行い、鈴木さんからのフィードバックも反映して初期版を完成させました。最後に、仕様、使い方、未実装項目、本番化に向けた検討事項をプロジェクト資料へまとめ、次に開発する人が判断の経緯まで確認できる状態にしました。
気づき、学び
AIと人間の役割を分ける
AIの並列活用によって、設計から実装までを短時間で進められました。一方で、速さを優先すると、実装に対する自分の理解が追いつかなくなります。そのため、AIに何を任せ、人間がどこを確認して意思決定するのかを、事前に分けることが重要だと感じました。 AIの出力をそのまま受け入れず、ドキュメントとコードを照らし合わせ、自分の言葉で説明できる状態にすることが、AIを使う側の責任だと学びました。
判断の過程を残す
実装前に不採用案まで設計書へ残すことで、実装中に判断がぶれにくくなりました。また、翌日に判断の詳細を忘れても、何を比較し、なぜその案を選んだのかを振り返れました。毎朝、前日の記録を読み返すことも、判断の軸を保つ上で役立ちました。
設計に迷ったときは、「本当に検証したいものは何か」に立ち返り、機能を切り捨てる判断も必要です。特に短期間の初期開発では、機能数よりも中心となる仮説を動く形で示すことが重要だと学びました。
ユーザーとビジネスから実装を考える
実装では、技術的に動くかだけでなく、ビジネス上の利点や、ユーザーにとって理解しやすいかを考える必要があります。小さなアプリでも、誰がどのように使うのかをユースケースとして整理するだけで、伝わりやすい画面に近づけられました。 一方、より大規模なアプリのフロントエンドでは、エンジニアだけで決めず、デザイナーと細かくすり合わせることも欠かせないと感じました。
VISIONを考え直す
5日間、さまざまな社員の方とランチや1on1、ミーティングをして話を聞く中で、自分は本当に「ビジネスとエンジニアリングの両方の視点を持ち、橋渡しをする」ことを目指したいのか、改めて疑問を持ちました。
3日目の夕方から夜にかけて深掘りした結果、大きな目標を掲げるだけではなく、目標をより小さな粒度に分け、まずは数年後に努力すれば届きそうなビジョンとして持つことが大切だと気づきました。インターンは、当初のVISIONを確認するだけでなく、自分に合った形へ見直すきっかけにもなりました。
数値で振り返る成果
8月31日の開発開始から9月3日の初期版完成までに、122ファイルを追加・更新し、60件の作業コミットを作成しました。また、16件のPRがマージされ、57件のADRを残しました。
CTOのレビューを通したADRと、開発中に残したADRでは承認状況に違いがありますが、当初掲げた3〜5件の10倍を超える設計判断を記録できました。AIで開発を加速させながら、人間が意思決定とその記録に責任を持つという、今回目指した開発スタイルを成果として示せたと感じています。
また、CIOの鈴木さんに直接成果をプレゼンし、フィードバックをもらう機会もいただきました。自分が一から作った基盤をさまざまな立場の方に何度も説明し、意見を受けて改善する経験は、当初予定されていた業務だけでは得られない、とても価値のある学びになりました。
おわりに
今回のインターンでは、全社展開を見据えたJITアクセス管理基盤の初期版を完成させ、AIを並列活用した開発と、自分で意思決定した過程を残す経験ができました。テストやレビューに加え、判断とその理由をドキュメントに残すことで、高速に実装を進めながら品質を担保しました。 この経験を通じて、AIを使って速く作るノウハウは、インターン前よりも身についたと実感しています。一方で、AIが提案した設計を適切に評価し、採用するかを判断するためには、自分自身の知識が必要だとも再認識しました。 今後、AIによる開発速度はさらに上がっていくと思います。その中で、AIを並列化して速く作る力と、自分で知識を吸収し、理解した上で判断する力の両方を伸ばしていきたいです。
最後に、5日間を通して伴走してくださったメンターの石田さんをはじめ、レビューやフィードバック、1on1などで関わってくださった皆さま、本当にありがとうございました。今回得た学びを、今後の開発や活動に生かしていきます。
