コードを書かないマネージャーがつくるコンテキストエンジニアリング / Context Engineering Created by a Non-Coding Manager

◆イベント名
AI導入最前線！理想 vs 現実『AIドリブン開発』 〜エンジニア視点で語るリアル活用術〜
https://connpass.com/event/370611/

◆発表タイトル
コードを書かないマネージャーがつくるコンテキストエンジニアリング

◆登壇者
株式会社ラクス　AIエージェント開発課 課長　石田 浩章

Transcript

1. © RAKUS Co., Ltd. AI駆動開発の "壁"を壊すのは、コードではなく文脈だった 2025/09/30 ⽯⽥ 浩章 株式会社ラクス コードを書かないマネージャーがつくる コンテキストエンジニアリング
2. ”2つのチームと3つの役割 ” ２つのチームの課⻑職を兼務し組織横断の３つの役割 • 楽楽電⼦保存のチームのマネージャー • AIエージェント開発チームのマネージャー＋PdM • 所属部署のAI駆動開発の推進者 2 登壇者紹介 ⽯⽥ 浩章 楽楽明細開発部 開発2課 課⻑ 楽楽精算事業部 AIエージェント開発課 課⻑ 2024年10⽉ 株式会社ラクスに⼊社 アプリ開発の中での話をします♪
3. © RAKUS Co., Ltd. ⽬次 • 導⼊: 既存開発にAIが導⼊しづらい３つの"ない" • 次の時代のエンジニアリング • マネージャーとして取り組もうとしていること
4. © RAKUS Co., Ltd. 4 導⼊: 既存開発にAIが導⼊しづらい３つの"ない" #RAKUS Meetup
5. 機能A’’’を改修しようとして ある仕様の決定経緯を誰も知らない！ （積み重なった機能や仕様だけでは） 機能単位での仕様書があっても、 システム全体の機能や画⾯を把握す るのは困難になっていた。 ⼀度に理解できる量ではない 全体的な仕様が把握できない 5 既存開発へのAI導⼊を阻む３つの"ない" あるシステムの歴史 機能A 機能B 機能C 機能D 機能A’ 機能Z 機能A’’’ ⻑ い 期 間 過去の設計履歴がない PJ内のソースコードが膨⼤すぎ て、AIが１度に扱える情報量（コ ンテキストウィンドウ）を越えて いた。 ⼤量の機能や画⾯ 俯瞰的に整理された仕様書がない！ ドキュメントが整理されていない！ コード量が多すぎて、コーディングエージェ ントに読み込ませられない！ ⻑期開発のプロジェクトでは、仕 様決定の背景が失われがちです。 景や議論の経緯が失われ、意思決 定の⽂脈が追えない。
6. © RAKUS Co., Ltd. 6 次の時代のエンジニアリング #RAKUS Meetup
7. 7 これからの鍵は「コンテキストエンジニアリング」 AIの真価を引き出す新技術 コンテキストエンジニアリングとは、AIが⼈間の意図を正確に理解し、適切な応答を⽣成するために必要な 「情報（コンテキスト）」を設計‧構造化する技術です。 ※ Google DeepMindのシニアAIリレーションエンジニアであるフィリップ‧シュミット ⽒のブログ（https://www.philschmid.de/context-engineering）より引⽤ - The magic isn't in a smarter model or a more clever algorithm. It’s in about providing the right context for the right task. （意訳） - 重要なのは、より賢いモデルではなく、課題に最適なコンテキストを与え ること。
8. 様々なAIコーディングエージェントを試す中で、新規開発ではある程度効果を発揮するものの、 ⻑期に渡って開発されてきた複雑なシステムへの導⼊は難しいものがありました。 • DevinやClaude Codeなどを調査‧検証 ◦ 簡単なアプリケーションは驚くくらい簡単にできる！ • 各チームで導⼊を進めてもらう ◦ 完了できたのは、簡単なタスクのもののみ • その他に直⾯した問題 ◦ 既存コードから仕様検討や提案させても期待した結果はでてこない ◦ 多くのタスクで、プロンプト（指⽰出し）や修正に時間がかかってしまう 8 コーディングエージェントが実開発で⼒不⾜な理由 課題: 新規開発と既存開発のギャップ ⻑期の開発においては、チームに蓄積された暗黙知（コンテキスト）に⽀えられていることを実感
9. © RAKUS Co., Ltd. 9 マネージャーとして取り組むこと #RAKUS Meetup
10. 10 コンテキストエンジニアリングを阻む3つの壁 多様な関係者 失われたコンテキスト 同じエンジニアでも、プロンプトスキルやAIツールの活⽤レベルに差がある！ AI活⽤のスキル格差 既存のコードや仕様書には、そのコードが書かれた背景や意図といったコンテキストがす でに失われていることが多い。 実サービスのエンジニアだけで開発しているわけではない！ ドキュメント管理においてエンジニアはGithub ‧ビジネスサイドはWordを好む
11. 設計以降のフェーズでは、 AIが扱いやすいMarkdown形式に 切り替えて扱っていく 11 解決策①：コンテキストストリーム設計 開発側が管理しやすいMarkdown形式で、具体的な システム設計や仕様をGithub上で管理。Claudeや CursorなどのAIツールとも連携しやすい。 設計‧実装‧テストはGithubで ビジネスサイドも扱いやすいGoogleドキュメントで 要求定義までの情報を管理。Geminiとの連携で効率 化も図る。 上流⼯程はGoogle Workspaceで 全社で利⽤されており、誰でも扱い！ 迅速な仕様決定のために、扱いやすい フォーマットで情報を蓄積する フォーマット 変更
12. 12 解決策②：AIによる⾃動化と⽀援 例えば「電⼦帳簿保存法」のような専⾨知識が必要 な要件について、AIが仕様書の整合性をチェック。ド メイン知識に依存せず品質を担保する。 専⾨知識や属⼈性の排除 Googleドキュメントで決定された仕様を、AIが⾃動 でMarkdown形式に変換し、Githubに転記する。⼿ 作業による転記ミスや⼿間を削減する。 カスタムスラッシュコマンドでの⾃動化 > 電⼦帳簿保存法を元に仕様を確認してください ※ Claude codeでの利⽤を想定しています ※ プロンプトは意図的に変更しております > /new-feature WebAPI連携
13. Googleドキュメントには、１つの開発に関する情報 をすべて残す。（ドキュメントタブを活⽤） 13 解決策③：できる限りの情報を残す 技術設計にADRの活⽤ 上流⼯程での取り組み １つの機能開発単位での情報 ADR（Architecture Decision Record） = アーキテクチャ決定記録 ADR-001: 外部システム連携のためのAPIアーキテクチャ ステータス: 承認済み ✅ ⽇付: 2025/09/26 1. 背景 (コンテキスト) 電⼦帳簿保存法の改正（特に2022年1⽉施⾏分）により、国税関係書類（請求書、領収書など）の電⼦データ保存が義務化‧促 進されています。多くの企業では、会計システム、経費精算システム、販売管理システムなど、複数のSaaSや業務システムを 利⽤しており、これらのシステムで発⽣する電⼦取引情報を、本ストレージシステムに集約‧保存するニーズが急速に⾼まって います。 （中略） 2. 決定事項 外部システム連携機能として、RESTful API を採⽤します。具体的な技術仕様は以下の通りです。 - APIスタイル: REST (Representational State Transfer) - HTTPメソッド (GET, POST, PUT, DELETE) を活⽤し、直感的で分かりやすい操作体系を提供します。 - データ形式: JSON (JavaScript Object Notation) ## 認証⽅式: OAuth 2.0 (Client Credentials Grant フロー) - システム間の連携に特化した安全な認証フローを採⽤します。 - アクセストークンには有効期限を設け、必要に応じてリフレッシュする仕組みを導⼊し、不正アクセスリスクを低減 電⼦帳簿保存法対応: タイムスタンプ付与: ファイル登録APIの実⾏時に、認定タイムスタンプを⾮同期で付与するプロセスを内部で実⾏します テンプレートを元に必要事項をテキストで残す
14. 14 これが最適解だとは思っていませんが、 チームメンバー‧関係者‧AIエージェントが より良く開発していける環境を整備することが マネージャーとしてのコンテキストエンジニアリングです