ラクス Advent Calendar 2025

AI活用前提で考える開発プロセス設計

Last updated at 2025-12-09Posted at 2025-12-09

はじめに

これはAIを活用した開発のプロセス設計に関する記事です。

AIを導入したが思ったほど生産性が上がらない。どこから手を付けていいかわからない。など思ったことはありますでしょうか。

AIコーディングツールが普及した今、単に「コードを書く速度」だけを追い求めても開発全体の生産性は頭打ちになります。本記事では、どのようにして既存のプロセスを「AI活用前提」のものに変更していくかを前半に、現状私が考えている理想の状態を後半に記載します。

一般のアプリケーション開発者が、いかにしてAIをチーム開発に組み込み、実用的な生産性向上を実現するかという視点でまとめています。

前半：既存プロセスをどう「AI仕様」に変革するか

AIを単なる「壁打ち」「コード生成」ツールとして使うだけでは、開発プロセスは変わりません。既存のプロセスをAIが最大限力を発揮できる形へ移行するには、「人間が暗黙的に行っていたことの形式知化」 と 「情報の入出力設計」 が不可欠です。

1. 脳内コンテキストの「外部化」と「標準化」

従来の開発ではドメイン知識や命名規則、アーキテクチャの判断基準は、熟練エンジニアの頭の中（暗黙知）にありました。しかし、AIにはそれが通じません。AIが迷わず動ける状態を作る必要があります。

命名・用語の統一
- 画面名、機能名、変数の命名規則を統一します。
- AIが「自然言語の仕様書」と「実際のコード」を正しく紐付けるための共通言語となり得るように、コード側も命名を合わせます。その場合 ドメイン駆動設計（DDD） の考え方が非常に相性が良いです。
  - 仕様書上の「注文」がコード上で Order なのか Purchase なのか揺れているだけでAIの精度は落ちます。
  - 完全にDDDが難しい場合でも、日本語名称とコード上の英単語をマッピングした辞書を用意し、AIに参照させるだけで精度は向上します。
ドキュメントの構造化
- 仕様書、設計資料、マニュアルをLLMが読み取りやすい形式（Markdown、JSON、TOON等）で管理します。
- GoogleドキュメントなどでもAIが参照できれば問題ありませんが、読み込むのに時間がかかる場合があります。
- DB定義であれば、DBスキーマを直接参照するMCP（Model Context Protocol）サーバーを活用し、リアルタイムな構造をAIに把握させる事もできるでしょう。
過去資産のモジュール化
- 「こういう時はこうする」というパターンとして整理し、AIが参照可能な状態にします。
  - 過去のテストケース（入力・操作・期待値のセット）
  - 問い合わせのトラブルシューティング履歴
  - 不具合の原因、対応方針、結果

これらがAIから参照(ファイル読み取りや取得)できるようになっていない場合は、まず取得できるようにする必要があります。

暗黙知になっていてどこにも記載がないなら作成する
APIやMCPを利用して取得できるようにする
一定間隔で取得しておき最新化しておく
- ※また膨大な量のドキュメントもまた読み込むことが難しくなるため分割して必要な所だけ参照できるように構造化を考える必要もあります。
  - これは人間が読む場合もそうですが、一度に大量の情報は保持できない or 時間がかかります。
AI自体にドキュメント生成を依頼する

2. タスクの「分割」と「注入」

現在のLLMにはコンテキストウィンドウ（記憶容量）の制限があります。また、関係のない情報を渡すことはノイズになり、推論精度を下げます。要件を丸ごと渡すのではなく、AIが処理可能な粒度まで分解するフローを導入します。

MECEな分割: 要件定義を機能単位、ユースケース単位などで漏れなくダブりなく分割します。
必要な情報の注入: 分割された1つのタスクに対し、必要なドメイン知識、関連コード、DB定義のみをピンポイントで渡せるようにディレクトリ構成や参照ルールを整備します。「全ファイルを読ませる」のではなく「必要なコンテキストのみを注入する」技術が重要です。

3. 出力の「テンプレート化」による品質担保

「出力結果を指定しない」は禁止です。AIのアウトプット品質を安定させるために、出力フォーマットを厳格に定義します。

テンプレートの強制: 設計書やコードを出力させる際は、必ず決まったテンプレートやルールを使用させます。
「分からない」を言わせる: テンプレートには「判断できたこと」だけでなく、「判断できなかったこと（不足情報）」とその理由を書かせる欄を設けます。
- これによりハルシネーションを防ぎます。
- 人間はまずこの「判断できなかったこと」だけを集中的にレビューし、不足した情報を補います。
  - 不足した情報が横断的な内容であればコンテキストとして形式知化も検討できます。
AIによる相互レビュー: 成果物をすぐエンジニアが確認するのではなく、別のAI(モデル違い、LLM違い、コンテキスト無し)にレビューさせ別の視点のレビューをさせます。

中間：どこからAI活用を始めるか

前半では「AIが動ける環境を整える」準備について述べました。
後半では理想の開発フローを描きます。しかし、全てを一度に変えることは現実的ではありません。

まずは現状のプロセスを分解し、どこから着手すべきかを可視化します。

1. プロセスの分解

現状の業務を「大項目→中項目→小項目」で分解します。ポイントは小項目まで落とすことです。「設計」という粒度ではAI化の可否を判断できませんが、「API仕様書の作成」まで落とせば判断できます。

2. 評価表の作成

分解した小項目ごとに「効果」と「難易度」を評価します。

小項目	現状工数(h)	頻度(/月)	効果(h/月)	難易度
コードレビュー対応	0.5	40	20.0	2
API仕様書作成	2	8	16.0	3
テスト項目作成	1.5	8	12.0	2
原因調査	1	12	12.0	4
議事録作成	0.5	20	10.0	1
類似事例検索	0.3	20	6.0	3
進捗集計・通知	0.25	20	5.0	1
非機能要件チェック	0.25	4	1.0	1

効果 = 現状工数 × 頻度

※ここでは例として「API仕様書の作成」という粒度で小項目にしてますが、より細分化できるのであればした方が良いです。例えばSwaggerで作っているなら「PRの準備」「エンドポイント作成」「リクエスト・レスポンスパラメータ作成」「エラーレスポンス作成」「PR更新」「レビュー依頼」といった感じです。

難易度の目安

難易度	意味
1	すぐできる。既存ツールの設定程度
2	テンプレートやプロンプト整備が必要
3	MCP構築やデータ整備が必要
4	複数システム連携や大きな前提整備が必要
5	技術検証から必要、実現可否が不透明

3. 優先順位の判断

効果でソートしつつ、難易度を見て選びます。

効果:高 × 難易度:低 → 最優先
効果:高 × 難易度:高 → 計画的に準備を進める
効果:低 × 難易度:低 → 余裕があればやる
効果:低 × 難易度:高 → 後回し

まずは自チームの業務でこの表を作ってみてください。どこから手をつけるべきかが見えてきます。

後半では、この評価を経て最終的にどこを目指すのか、理想の開発フローを描きます。

後半：AIコーディングエージェントを中心とした理想の開発フロー

ここからは前述の準備が整った上で理想の開発フローを描きます。

エンジニアは利益を得るための価値提供する要件を元にアウトプットを行いますが、その達成のために様々なツール・サービスや知識を駆使してやってきた従来の方法と、AIを使って達成することに変わりは無いです。ただ今まで人が自然言語処理や手作業を使ってきたことが代替可能になってきた上に早いのです。少なくとも今はそれを利用しない選択肢は無いと考えます。
私たちの役割は、手作業によって詳細な設計やコーディングから、AIに適切なコンテキストを与え、創出された成果物の品質と正しさを保証する活動へと、その価値提供の焦点を移していきます。

※私の実態としてまだ道半ばの部分があり、ここに書いていることの2、3割程度の達成度です。
※共通の内容としてAIが何かを生成してエンジニアの判断が必要になったら、slackなどに通知が飛びます。

開発フロー

1. 要件定義

「要件」をユースケース毎に分割させ、テンプレートを埋めさせ資料を作成する
- 例えばエラーパターンなど要件に含まれていない部分は洗い出す
- パフォーマンス、セキュリティや後方互換性など非機能要件はチェック項目で確認させる
- エンジニアはレビューを行い、AIは指摘を修正する
NotebookLMを利用してステークホルダーと合意するための説明文を生成する（技術が向上してこれば説明動画も作れるのことを期待）
- ステークホルダーは説明文を確認し、コメントを行う
- エンジニアはそれを元にAIと修正を行い、完成に近づける

2. 設計

AIが1で作成した要件定義の資料、デザインデータが揃ってステータスがreadyになったことをトリガーに、既存のコード、DB定義を利用して設計書をテンプレートを埋めさせて作成する
- マークダウン管理されており、設計が出来上がるとPRが作られる
  - AI側での不明点はPR上でコメントがされていて、解決するまではマージしないように運用する
- 設計書が完成したらslackで通知
- エンジニアはコードレビューをする感覚でコメントをつける
- AIがコメントを元に修正を行う
  - この時にコンテキスト不足が原因の指摘の場合はエンジニアから得られた情報をコンテキストデータに追加する
ユースケースの規模が大きい場合はさらに分割してから設計する

設計書には仕様、完了の定義、クラス図、データフロー図、API仕様、DB定義などが盛り込まれる

3. テスト計画、項目作成

テスト項目の作成はユニットテスト、単体テスト、結合テストで重複が無いようにテスト計画のマークダウンが作成され、これもPRが作成される
- 詳細なテストケースを網羅した内容ではなく、因子水準レベルの資料を作成
別のAIが1次レビューを行い不足がないかチェックする
その後エンジニアは内容をレビューし、AIは指摘を修正する
AIは因子水準から単体、結合テスト項目を作成（スプレッドシートなど）
エンジニアがレビューし、AIもしくはエンジニアが修正する

※実装前にテスト計画を立てることでより実装前の考慮漏れを防ぐことが可能です

4. 実装

AIが2で作成した設計書と3で作成したユニットテストの方針を元に詳細な実装のTODOリストを計画する
エンジニアはそれをレビューし、問題なければ実装を開始する
実装中AIはTODOリストを進捗に合わせて随時更新する
- ビルドやユニットテストはAIが実行しエラーになる場合は自己修正する
別のAIで結果をレビューし、実装AIはFBを元に修正する
完成したらPRがオープンされエンジニアがレビューし、AIが指摘を修正する
問題なければエンジニアがマージ
3のテスト計画、項目を実装結果を元に更新

5. テスト

手動で行うテストもplaywrightやcurlコマンド実行などで行うものはAIが担当
- 実行のログも出力させ、結果とともに別のAIがチェックを行う
- NG項目はまとめてslackに通知
AIが不可能な部分は人が対応する

運用・保守

6. 不具合対応

AIがコードを調査し、原因、対応方針(3案)、メリット・デメリット、工数を生成
エンジニアが方針を判断
以降は2の設計と同じだが、簡単な対応であればdevinやcodex、claude code(web版)などを使ってMTG前、退勤前、週末などに依頼して対応も視野に入れる

7. 問い合わせ対応

AIが類似の過去問い合わせ、各種ログ、マニュアル、既存コードを参照し、仕様なのか不具合なのかを調査してレポートにまとめる
エンジニアがレビューして、AIとレポートを完成させる
レポートを元に回答を作成する

チーム運営

8. 朝会

AIが毎朝タスクの消化状況を取得し、スプリントの進捗状態が見える化
遅れがあれば対象者にslack通知し、対象者が状況を共有する
あらかじめタスクの優先度は決まっており、AIがタスクを減らす、優先度の変更などを提案する
それを見てエンジニアチームが今後の対応を判断する（これに集中する）

9. 技術情報収集

最新技術、競合の動向、アップデート情報、脆弱性、などあらゆる技術的な調査はAIが定期的に行い、レポートにまとめる

10. PoC作成

AIが9の情報を元にPoC案を週次で生成
- web上で簡単なデモを見れる
案を採用に変更するとdevinやcodex、claude code(web版)などが実際にPoCを生成する
実際に試せるものが利用できるようになっており、エンジニアが軽く動作確認して問題なければ関係者にリンクをslack通知

11. 会議（議事録）

Googleカレンダーの設定でMeetであれば録画と文字起こしが可能
- ※基本的には自動で録画、文字起こしするように設定し、それが普通の状態にするべき
議事録リンク、要約とネクストアクションはslackに投稿させる

12. 技術判断

技術的課題に対してロールが違う複数のAIに3案ずつ解決方法を提出させる
その案の中からメリット・デメリット・工数を鑑みて推奨案を出させる
エンジニアはそれを参考にしつつその案の中から選ぶか壁打ちを行い、対応策を検討する

13. 計画

AIに特定の計画を立ててもらい進捗チェックをさせる
- 例えば技術負債解消を1日あたり30分程度やる場合
- AIがいつまでに何を終わらせるかを期限からマイルストーンを逆算する
- Googleカレンダーに期間予定を追加する
- 進捗はマークダウンのチェック形式で管理されており
- AIが定期的に確認して、遅れがある場合はSlack通知される

個人の成長

14. 自己評価

チャット履歴からの「実績の可視化」と「自己評価」
エンジニアの評価において、「自分が期中に何をやったか」を思い出し、アピール資料を作るのは大きな負担。これをAIで自動化します。

Slack等の履歴の活用
- 自身の発言履歴、マージされたPull Request、ResolveしたチケットのリンクをAIに読み込ませます。
評価資料の生成:
- 評価プロセスにおいて、日々の活動記録（チャットやGitログなど）をAIが参照し、埋もれがちな貢献を含め実績で可視化することで、評価資料作成の負担を大幅に軽減します。
- 「埋もれていた貢献」（例：若手への技術的アドバイスや、仕様の矛盾点の指摘など）も漏らさず評価テーブルに乗せる
- ※会議の議事録なども自動生成しておくと活用できるでしょう

15. キャリアパス

AIが会社の職務要件、前回評価、技術ロードマップなどから現状のスキルセットを比較させ、埋めるべきギャップをリストアップ
上司との1on1前に、話すべきキャリアトピックや質問を整理させる
- 14の内容も考慮しつつ、前回の1on1内容と今回の進捗を比較したサマリを生成

まとめ

AI活用開発において最も重要なのは、AIの能力そのものよりも、 「AIが迷わずに仕事ができる環境（コンテキスト）を人間がどう整えるか」 にあります。

コーディング: 暗黙知を形式化し、コンテキストとして注入する。
運用: 過去の事例をパターン化し、判断材料として渡す。
マネジメント: 散らばったログを集約し、評価や進捗の材料として加工する。

これが私が考えるこれからの開発の理想形です。

最後に

色々と書きましたが、忘れてはいけないのはこれらを支えるのはこれを行う人間の基礎力だということです。何事にも深い理解が必要です。
また、具体的な作業や細かい判断などをしなくなった結果、今までは苦労したからこそ覚えていた「この前やったアレ」を思い出せなくなる可能性もあります。ただその時も形式知化されたデータとAIがサポートしてくれるはずです。

余談：チーム・組織への展開

「体験しないと価値がわからない」問題

少し別の話になりますがAI活用の障壁は、技術的なものもありつつ最初の一歩として認知の壁です。

強力なAIの価値は体験しないとわからない。しかし体験するには、既存の業務や生活がある中で変化を受け入れ、学習コストを払う必要がある。結果として「今のやり方で回っている」チームほど、変える動機が生まれにくいという構造があります。

また、特定の人が成果を出しても「あの人だからできた」で終わってしまっては、組織としての生産性向上にはなりません。誰でも追える再現性を持たせることが不可欠です。

私が試しているアプローチ

現在以下の2つのアプローチを並行して進めています。

対象	手法	狙い
同じチームのメンバー	ハンズオン形式で実際に手を動かしてもらう	体験を通じて「これは便利だ」という実感を得てもらう
他チーム	デモ動画と簡易ガイドの配布	興味を持った人が自走できる入口を用意する

正直なところ、後者は感度の高い人にしか届かないという課題があります。動画を「見てもらう」こと自体がハードルであり、5分の動画でも長いと感じる人は多いです。

まだ正解は見つかっていない

情報を置いておくだけでは、イノベーター〜アーリーアダプター層にしか届きません。マジョリティに届けるには、おそらく以下のいずれかが必要になると考えています。

「意識せずとも活用できる状況」を作る
- 特定の業務フローにAI活用を組み込む
数字で示す
- 「この作業が3時間→30分になった」という具体的な成果は、体験がなくても刺さる人には刺さる

おわりに

これらも試行錯誤の途中であり、「こうすればうまくいく」という確立した方法論はまだありません。同じ課題を抱えている方がいれば、ぜひ知見を共有いただければ幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up