コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知

2025/07/24 開催の「レバテック Meetup ～AIエージェントと共に進化する開発現場～」での登壇資料です。
https://levtechcareer.connpass.com/event/360710/

Transcript

1. レバテック開発部 ビジネスサポートグループ 前原 宗太朗 コンテキストエンジニアリングで変わるAI活用 リファクタリングワークフローの実践から学んだ形式知
2. |　© 2025 Levtech Co., Ltd. 2 レバテック開発部 前原 宗太朗 SOTARO MAEHARA 2022年6月入社 レバテック開発部ビジネスサポートグループ バックエンドエンジニア 出身: 鹿児島 言語: C++ / Go / Python / TypeScript / PHP / Rust 趣味: League of Legends / Team Fight Tactics
3. |　© 2025 Levtech Co., Ltd. 3 コンテキストエンジニアリングをリファクタリングのタスクに適用して AI活用においての「なんとなくうまくいく」を形式知に変換する取り組み 今日話すこと
4. |　© 2025 Levtech Co., Ltd. 4 導入状況 レバテックのAI活用の現在地 活用事例 • ライブラリバージョンアップのリスク評価 • 問い合わせの際のDeepWiki活用 • AIコードレビュアーによる1次レビュー etc. https://zenn.dev/levtech/articles/4b540d6398bda1
5. |　© 2025 Levtech Co., Ltd. 5 費用対効果は定性的に評価 レバテックのAI活用の現在地 Good • 想定1時間の実装が10分で完了した • 叩き台を作ってくれたので、サンプル で学びながら効率よく実装できた • レビュアーのレビュー工数が大きく減 少したと感じている More • 細かい部分を指定しなかったため、指 摘する部分が多くACUが高くなった • 作業時間は早いが出来上がったソース に対し、修正が必要だった • プロンプトを改良すれば解消するかも 概ね世間で言われていることと同じ評価
6. |　© 2025 Levtech Co., Ltd. 6 開発現場は進化したのか？ 体感としては大きく変化した。しかし「何が・どう変わったか」を言語化し切れ ていない 個別でうまくいっている事例やTipsの共有はあるが、体系化された形式知はシェ アされていない 「こうすればうまくいく」というHowは多く語られる一方で、 「どんな状況で、なぜそれが機能するのか」という Why / When はほとんど 明文化されていない レバテックのAI活用の現在地
7. |　© 2025 Levtech Co., Ltd. 7 形式知を手にいれるための取り組み • 事例を調べる ◦ その分野の最前線ではどんな議論がされているのか • 対象領域を見極める ◦ 我々が管理するシステムにおいて、 「どんな状況下」で「どうやったら」うまくいくのか • 仮説を小さく実践し、検証する レバテックのAI活用の現在地
8. |　© 2025 Levtech Co., Ltd. 8 世の事例を調べる コンテキストエンジニアリングという言葉が広まりつつある プロンプトの表現よりも、与えるコンテキストを重要視 失敗の多くの要因はモデルの推論能力ではなく コンテキストの不足によるもの 気になる人はAwesome Context Engineeringで検索してください The rise of "context engineering" https://blog.langchain.com/the-rise-of-context-engineering/ Awesome Context Engineering https://github.com/Meirtz/Awesome-Context-Engineering
9. |　© 2025 Levtech Co., Ltd. 9 12 Factor Agents エージェントを安定して再現・運用でき るようにするための12の設計・運用原則 Webアプリケーション向けの原則だが、 開発プロセスも「定式化されたタスク」として 抽象化すれば応用可能 世の事例を調べる https://github.com/humanlayer/12-factor-agents
10. |　© 2025 Levtech Co., Ltd. 10 12 Factor Agents 特に気になったのがFactor12 • ワークフロー全体のほとんどを決定論的な ものとして設計し、要所でエージェントを 使うこと • 小さなエージェントをステートレスのリ デューサーにする 世の事例を調べる https://github.com/humanlayer/12-factor-agents
11. |　© 2025 Levtech Co., Ltd. 11 １つの長いタスクを、小さなタスクに分割 各ステップで成果物を出力、その成果物を次のス テップの入力にする 何が嬉しい？ • 各ステップが単一責務になる • 短いタスクに必要最小限のコンテキストを与 えることによって出力のブレが減る • ステップごとに中間生成物ができるので 差分レビュー可能 世の事例を調べる Long Task Output 指示 TaskA TaskB TaskC 成果物1 成果物2 成果物3 In ガイドライン Out Out In Out 指示 非決定論的な要素が多い 全体を決定論的なワークフローとして要所でエージェント
12. |　© 2025 Levtech Co., Ltd. 12 我々が管理するシステムにおいて、「どんな状況下」で「どうやったら」うまくいくの かを考えるのも重要 コンテキストの不足が主な失敗要因であることから、コンテキストの失敗を注意深く 観察する必要がある ⇨ プロセスの改善に対して、人間の介入がある程度は必要 仮説 単発のタスクをAIに丸投げするよりも、繰り返し発生するスケーラブルな作業を任せる 方がより効果的ではないか？ 対象領域を見極める
13. |　© 2025 Levtech Co., Ltd. 13 レガシーシステムのリファクタリングタスク • 発表サマリ ◦ １つのモデルが26の状態を持つ ◦ 120のnullableカラム ◦ 1,000行を超えるのRequestValidation 古き良きLaravelシステムに対して、関数型スタイルでリファクタリングをしたお話 リファクタリングの手法は確立できているものの、途方もない作業量 対象領域を見極める https://speakerdeck.com/leveragestech/gu-kiliang-ki-laravel-nosisutemuha-guan-shu-xing-sutairuderihuakutadekirunoka
14. |　© 2025 Levtech Co., Ltd. 14 まずは雑にやってみる 1. リファクタリングのPRを参考に 手順・ガイドラインを作成 2. ガイドラインを参考にリファクタ リングを行うように指示 雑な指示だけど、ステップにも分かれてるしうまくいきそ〜 実践編
15. |　© 2025 Levtech Co., Ltd. 15 雑にやってみた所感 • 出来上がったPRを見ても良し悪しの判断が難しい • テストは大半が失敗し、追加指示が必要 ◦ 実装はおろかテストの作成すら失敗している • 無関係な探索を繰り返すケースが多発 • 複数回実行すると出力がばらつく 実践編 不安定かつ失敗の原因もわかりづらい、実行時間も長いので改善も回しづらい ⇨ コンテキストエンジニアリングを念頭に12 Factor Agentsを実践
16. |　© 2025 Levtech Co., Ltd. 16 1. ワークフロー全体のほとんどを決定論的なものとして設計し、要所でエー ジェントを使うこと 2. 小さなエージェントをステートレスのように設計する Point • 人の思考をトレースしステップを分割する ◦ 仕様理解→テスト設計→実装の順序を保つ • 観点が異なる単位でステップを分ける ◦ 観点が異なれば必要なコンテキストが異なる • どのような情報をインプットすれば単一のタスクがうまくいくかを考える ◦ エージェント間のコンテキストの引継ぎと必要な知識の両方 実践編
17. |　© 2025 Levtech Co., Ltd. 17 全体を決定論的なワークフローとして捉え、単一責務のタスクに分割 実践編 既存のコードから 仕様を抽出 仕様から テスト仕様書を作成 テスト仕様書から テストを生成 仕様書 テスト 仕様書 テストコード In テスト ガイドライン Out Out In Out Check！ ※ 本当はリファクタまでやる予定でしたがテスト作成するところ でつまりまくったので、テスト作成までをスコープとしてます
18. |　© 2025 Levtech Co., Ltd. 18 全体を決定論的なワークフローとして捉え、要所でエージェントを使う 実践編 既存のコードから 仕様を抽出 仕様から テスト仕様書を作成 テスト仕様書から テストを生成 仕様書 テスト 仕様書 テストコード In テスト ガイドライン Out Out In Out Check！ システムのリファクタリングを行います 特にExtraValidationなどの巨大なロジックをドメインモデルに移行した いと考えています。 ### 参考ドキュメント @docs/refactoring-analysis.md @docs/refactoring-guidelines.md Step 1: 仕様抽出 既存の実装から仕様を自然言語で抽出してください ### 対象コード $ARGUMENTS ### 出力フォーマット例: <ビジネスルールの概要>…</ビジネスルールの概要> <用語定義>…</用語定義> <事前条件>…</事前条件> <不変条件>…</不変条件> <ビジネス上の意味>…</ビジネス上の意味>
19. |　© 2025 Levtech Co., Ltd. 19 観点が異なる単位でステップを分け、必要なコンテキストを与える 実践編 既存のコードから 仕様を抽出 仕様から テスト仕様書を作成 テスト仕様書から テストを生成 仕様書 テスト 仕様書 テストコード In テスト ガイドライン Out Out In Out Check！ 仕様通りかどうか 条件を網羅できているか？ 境界値は？ プラクティスに 沿った実装か
20. |　© 2025 Levtech Co., Ltd. 20 ワークフローを改善する • 単一のステップを複数回実行して出力が安定するようにプロンプトをチューニング ◦ 仕様抽出のステップで必要な用語の定義をしたりしなかったり • 失敗を観察する ◦ 何度か実行した結果、失敗のほとんどがテストデータの作成時の失敗 ▪ テストデータ作成のヘルパがエラー情報を提供していない ▪ 失敗の原因がわからず、無関係な探索を繰り返し、最終的には指示を無視する 実践編
21. |　© 2025 Levtech Co., Ltd. 21 全体を決定論的なワークフローとして捉え、必要なコンテキストを提供する 実践編 既存のコードから 仕様を抽出 仕様から テスト仕様書を作成 テスト仕様書から テストを生成 仕様書 テスト 仕様書 テストコード In テスト ガイドライン Out Out In Out ユビキタス言語と定数の定義を 出力のフォーマットに含める ヘルパ関数にエラーの コンテキストを含める Check！
22. |　© 2025 Levtech Co., Ltd. 22 実践編 結果 • 数十分試行錯誤して失敗していたテストの作成が一発で成功するように • 3回試行して3回とも成功 • 他のロジックに対しても追加の指示なく成功 After • 中間生成物を都度レビュー可能 • テストデータ作成のエラーを自力で解消 • 複数回実行しても出力が安定 Before • 出来上がったPRを見ても良し悪しの判断が難しい • テストの大半が失敗し追加指示が必要 • 複数回実行すると出力がばらつく • 無関係な探索を繰り返すケースが多発
23. |　© 2025 Levtech Co., Ltd. 23 実践編 所感 • 失敗の原因を早期に切り分けられ、試行錯誤のスピードが上がった • 各ステップで出力のブレを小さくするようにチューニングが効くので結果をコント ロールできている感覚を得られた • ルールを追加していくのが良いと思っていたのが、単一タスクでコンテキストを薄く 保つ方がうまくいくという肌感を得られた ワークフローの設計にはそれなりのコストがかかる ⇨ ワークフロー設計の初期コストを回収できるタスクに適用するのが効果的
24. |　© 2025 Levtech Co., Ltd. 24 生成AIの登場により開発現場の生産性は体感として向上した 「こうすればうまくいく」というHowは多く語られる一方で、 「どんな状況で、なぜそれが機能するのか」というWhy/Whenはほとんど 明文化されていなかった 全体を決定論的なワークフローとして捉え、要所でエージェントを使うことで なんとなく「うまくいく・いかない」問題をコントロール可能な問題に変換できる まとめ
25. |　© 2025 Levtech Co., Ltd. 25 Devinのセッションインサイト • Devinがタスクを遂行する上で詰まった 部分の分析 • 使用したトークン量の解析 • プロンプトの改善点の提案 このようなノウハウはツールに取り込まれている 余談
26. |　© 2025 Levtech Co., Ltd. 26 KiroのSpec Driven開発 • 要件定義 ⇨ 設計 ⇨ タスク分割の ワークフローを定型化 このようなノウハウはツールに取り込まれている 余談
27. |　© 2025 Levtech Co., Ltd. 27 今後は • モデルの性能の進化よりも、どんなワークフローであればタスクが成功する のかに関心が移る • エージェントがなぜ失敗したのかの可観測性が重要になる ◦ LLM Opsの分野は開拓されているが、それが開発プロセスにも波及する • このようなノウハウはツールそのものや周辺ツールとして取り込まれていく この辺りの話題に興味があるので、ぜひ懇親会で語らいましょう！ 最後に