はじめに
LIFULL Advent Calendar 2025 10日目の記事です。
普段はLIFULLのWebマーケティングに関連のバッチの運用とかレポート用のクエリの管理システムの運用とかやっています。
今回は流行りに乗って生成AIネタを書きます。
Introduction
みなさん、仕事で生成AI使ってますか?
私も使ってます。
でもChat形式のAIってダルくないですか?
<よくあるChatGPTやGeminiを用いた開発>
要件をチャットに書き込んで、生成AIが返した答えをエディタにコピペして、うんたらかんたら
まあ、面倒臭いですよね。
AIエージェント
ということで、時代は、AIエージェント!
LIFULLのエンジニアがよく利用しているAIエージェントにAmazonQがあります。
Kiro CLIを利用している人もいますが、私は VSCodeのAmazonQエクステンションを使っています。
チャット形式の生成AIとの違い
「時代は・・・」なんて言っておいてなんですが、UIがチャットなのは変わりません。
AIとのやりとりはチャットで行います。
ですが、AIエージェントにはContextを設定することができます。システムプロンプトの代わりにbasic-rules.mdのようなマークダウンファイルを用意し、そこにプロジェクトの決まりごとなどを色々と書き込んでおきます。これで安心。
# 基本ルール
- 日本語で応答する
- 作業時に情報不足の場合はユーザーに入力を求める
- 作業計画を立ててユーザーに合意を取ってから実行する
- **各作業ステップでユーザー承認を必須とする**(特に破壊的変更や複数ファイル修正時)
- **作業開始前に必ず事前調査を実施する**(ファイル構造、依存関係、既存実装の確認)
- **推測による記述を絶対に禁止する**(環境情報、コマンド、設定値等は必ず実確認)
- **ルール文書の完全確認を必須とする**(作業開始前にbasic-rules.md等を詳細確認)
(略)
# 作業環境
## 作業ディレクトリ
- メインディレクトリ: `./.qdev-working-memory/`
- 一時ファイルはここに保存し、作業後も残す
- タスク管理ファイル(tasks.md等)もここに配置
(略)
# プロジェクト進行フロー
## プロジェクト進行管理
**プロジェクト進行フロー**
- 事前調査 → ファイル構造・既存実装・依存関係の確認
- 要件定義 → `requirements.md`作成
- 設計 → `design.md`作成
- 実装計画 → `tasks.md`作成
- 実装 → プルリクエストベース開発
- 納品 → 成果物の最終確認
(略)
# JIRAチケット対応時の作業フロー
## 作業開始時の必須手順
### 0. 作業ディレクトリの作成
mkdir -p /app/$USER/.qdev-working-memory/[JIRAチケット番号]
cd /app/$USER/.qdev-working-memory/[JIRAチケット番号]
### ドキュメント管理ルール
- **必須**: 全てのJIRAチケット対応時は専用フォルダを作成
- **フォルダ名**: `/app/$USER/.qdev-working-memory/[JIRAチケット番号]`
- **保存対象**:
- `requirements.md`: 要件定義書
- `design.md`: 設計書
- `tasks.md`: タスク管理
- `implementation_summary.md`: 実装サマリー
- `final_summary.md`: 最終完了報告
- その他の分析・調査ファイル
(略)
そして、MCPサーバーと通信できるようにしておきます。(設定方法は省略)
LIFULL社内ではJIRAと通信できるMCPサーバーが存在しています。
実装の流れ
AmazonQに
次のJIRAチケットの対応して 「JIRA-0001」
と命令するだけ。
AIがJIRAから内容を読み取り、レポジトリ内のソースコードを読み取るなどしてから
.qdev-working-memory配下のチケットごとのディレクトリに
要件定義書: requirements.md
設計書: design.md
実装タスクリスト: tasks.md
などを作成します。
人間は、各ドキュメントをレビューして「承認します」「進めて」などと進めるだけ。
※ でたらめな実装することがあるので、要件定義や設計書の段階で綿密にレビューして間違いを指摘してあげましょう。
タスクリストを承認すれば、実装もAIがやってくれます。
要所要所で承認のステップを入れ、タスクリストの進捗を更新させるようにしておけば、万が一セッションが切れたりcontextがいっぱいになってクリアされても安心。
Contextを.qdev-working-memory/JIRA-0001から読み込んで続きをお願い
と命令すれば続きからやってくれます。
テスト仕様書を書かせたりもできますが、実装よりのテストになりがちなので、仕様に沿ったテストは人間が補完してあげる必要があります。
commitメッセージやPRもAIに任せで大丈夫。(basic-rules.mdにどのようなルールなのかを記載しておく必要はあります)
振り返り
最後に、チケットへの一連の対応が終わったら、AIに振り返りさせて、basic-rules.mdを更新させましょう。
こうすることで同じ過ちを繰り返させないようになります。
※ 結構繰り返すので根気強く振り返りとルールの更新を続ける必要があります
まとめ
生成AIとチャットするだけなんてもったいない!
色々任せてレビューして振り返りさせて、AIとの協業を深化させていきましょう!