AIによる開発の民主化を支える コンテキスト管理のこれまでとこれから

Transcript

1. 　 1 AIによる開発の⺠主化を⽀える コンテキスト管理のこれまでとこれから 2026年02⽉09⽇ 株式会社TOKIUM プロダクト本部横断チーム統括部 東 優太
2. 自己紹介 & 会社概要 2
3. ⾃⼰紹介 プロダクト本部 横断チーム統括部 イネーブリング 東 優太 Yuta Higashi 経歴 ネット広告会社のエンジニアとして初期のキャリアを 経験後、2020年に沖縄移住とともにTOKIUMに参加 2023年にイネーブリングチームに異動し、全体の⽣産性向上 に注⼒ 2025年6⽉にはAgentSDKチームとしてAI開発を補助‧促進 興味領域 Scala / Ruby / DDD / Scrum
4. 会社名 設⽴⽇ 所在地 従業員数 代表取締役 株式会社TOKIUM 2012年 6⽉ 26⽇ 東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 約240名 (2025年12⽉、正社員のみ) 黒﨑 賢⼀ 4 会社紹介
5. 「経理AIエージェントTOKIUM」とは 5 経理AIエージェント「TOKIUM」は、AIとプロスタッフが連携し、経理作業を丸ごと代⾏。 単に効率化するのではなく、作業⾃体を⼿放すことで「時を⽣み」、全社員が本来の業務に集中できる環境を実現。
6. ⽣成AIは開発そのものを変えてしまった
7. ⽣成AIは開発そのものを変えてしまった Product Dev PdM QA Before Product Dev PdM QA After
8. ⽣成AIは開発そのものを変えてしまった 誰でもプロダクトへ貢献できるようになった ⽣産量が簡単に向上するようになった 無秩序なコードが⾶び交うようになった 品質が簡単に低下するようになった しかし
9. ⽣成AIは開発そのものを変えてしまった ユーザーに投稿機能を実装して サーバー‧クライアントの2構成で す バックエンドはGo&Ginで Port&Adapterを採⽤しています クライアントはTS&Reactで Feature-Sliced Designを採⽤して います 機能実装時にはユースケース図 -> API仕様 -> 実装の順に進めます プルリクエストにはチケット番号 とfeature or bugのラベルを付け ます 期待したコードを引き出せるか？ 開発プロセスに沿っているか？ 管理ルールに従っているか？ ⽣成AIの性能を引き出すためには、 適切なコンテキストを与えることが 必要不可⽋ コンテキスト
10. 生成AIとうまく付き合うために、 コンテキスト管理に向き合おう
11. コンテキスト管理のこれまで
12. コンテキスト管理のこれまで 「こういう⾵に考えさせるとうまくいく」 といったプラクティスが探索され、 様々なプロンプトが社内でやり取りされた 管理されるというほどのものはなく、ド キュメントやチャットツールで共有される TOKIUMにおいては、むしろ開発者以外での 活発な共有が⾏われていた 黎明期: Prompt あなたはGASの開発者です スプレッドシートに定期的に書 き込むプログラムを作成してく ださい … 下記の⽂章を整理してください 誤字脱字を修正してください 表現をですます⼝調に直して... Prompt Prompt
13. コンテキスト管理のこれまで READMEに書かれるような設計ドキュメン トの流⽤から始まり、AIに知識を伝えること が本格化し始めた アーキテクチャやコーディング規約など、 たくさんの情報をなるべく詰め込む ツールを導⼊するたびに、 サポートするファイル配置が異なり、 1リポジトリの中でも管理に四苦⼋苦する バックエンドはDDD, Port&Adapterアーキテクチャ です CLAUDE.md バックエンドはDDD, Port&Adapterアーキテクチャ です AGENTS.md バックエンドはDDD, Port&Adapterアーキテクチャ です Knowledge 初期:Memory(Custom Instruction)
14. コンテキスト管理のこれまで 設計や実装を経て変わっていくドキュメン トをAIの⼊⼒‧出⼒両⽅に設定し、メンテ ナンスを⾃動化する⽅向へ ドメインモデリングやユースケース駆動な ど、設計のプロセスにAIを組み込んでみた ⼩さなうちは問題なかったものの、プロダ クトとドキュメントの拡張に伴って⼆重管 理に苦しむようになる 中期:Document ユーザーの投稿機能を実装して バックエンドはDDD, Port&Adapterアーキテクチャ で、ドメインモデルは model.mdです # model.md 投稿: タイトル‧説明⽂と投稿 者を持ったデータです Document
15. コンテキスト管理のこれまで コードレビュー‧プルリクエストの作成... 個⼈でもチームでも、頻出する使い⽅をコ マンドとし、細かな業務改善が進んだ MCPのPrompts機能は、カスタムコマンド として配布できることを発⾒し、社内ライ ブラリのセットアップなどをMCP化 コンテキストを配布可能に 後期:Command, MCP /tokium-setup MCP Server /tokium-update /tokium-oauth /tokium-template-server
16. 何をどうやってコンテキストに載せるべきか
17. 何をどうやってコンテキストに載せるべきか AIに作業をしてもらうときに、 考慮してもらいたいことはあまりに多い 「テスト通るまで修正して」 「仕様書はこのフォーマットで書いて」 「コードはここに配置して」 「残作業でTODOリスト作って」 「インフラ作るなら稟議必要ね」 「ブランチは feat/チケット で」
18. 何をどうやってコンテキストに載せるべきか コンテキスト上限が存在するため、 全部読み込んで考慮させることはできないし、 たくさん読み込むと遅すぎる ユースケースに応じて、必要なコンテキストだ けを読み込む必要がある
19. 何をどうやってコンテキストに載せるべきか スコープ 安定性 ⾼ 低 ⼩ ⼤ 安定性とスコープの2軸で考えてみる 安定性: 与える情報は変動的か‧固定的か スコープ: 与える情報は固有か‧⼀般か
20. 何をどうやってコンテキストに載せるべきか スコープ 安定性 ⾼ 低 ⼩ ⼤ 低安定性‧⼩スコープ = Prompt 「◦◦の機能を実装して」 「◦◦のコードをリファクタリングして」 載せる情報 = 達成したいこと Prompt
21. 何をどうやってコンテキストに載せるべきか スコープ 安定性 ⾼ 低 ⼩ ⼤ ⾼安定性‧⼩スコープ = Command 特定の⽬的を達成するための⼿順 「要件定義は下記の⼿順で進⾏」 「リファクタリングはまずテストを書く」 載せる情報 = 設計や実装などのプロセス Document Command
22. 何をどうやってコンテキストに載せるべきか スコープ 安定性 ⾼ 低 ⼩ ⼤ 低安定性‧⼤スコープ = Document プロダクトの進歩に伴って適宜更新しなが ら、必要な時だけ引き出したい知識 「名前が重複した時はエラーを出⼒」 「api/departmentsで部署⼀覧API」 載せる情報 = プロダクトの仕様や設計書 Document
23. 何をどうやってコンテキストに載せるべきか スコープ 安定性 ⾼ 低 ⼩ ⼤ ⾼安定性‧⼤スコープ = Memory プロダクトやシステム固有の常に意識した い情報 「ヘキサゴナルアーキテクチャに沿う」 「コンテナはこのコマンドで起動」 載せる情報 = アーキテクチャや慣例 Memory
24. 何をどうやってコンテキストに載せるべきか スコープ ⼩ ⼤ 安定性 ⾼ 低 Technical Context Business Context なにから整備に⼿を付けるべきか？ コンテキストはビジネス‧テクニカルの分 類に応じておよそ特性が決まってくると考え ている 技術構造は安定的でビジネス要求は不安定 安定させやすいテクニカルコンテキストか ら整備し、不安定なビジネスコンテキスト は軽量な⽀援から進めていくと良い
25. コンテキスト管理のこれから
26. コンテキスト管理のこれから Skill 特定の業務に関する知識や⼿順をパッケー ジ化 AI起動時に説明⽂のみを読み込み、 必要になってから全⽂‧リファレンスなど 段階的に読み込む 2025年12⽉にAgentSkillとして標準化され た 現在 要件定義‧仕様策定の知識を備 え設計を⽀援します Skill ユーザーの投稿機能を実装して セキュリティポリシーを備え コードレビューを⽀援します
27. コンテキスト管理のこれから スコープ 安定性 ⾼ 低 ⼩ ⼤ Skill 説明⽂からドキュメントへ、段階的に読み 込めるので、スコープと安定性が動的に変 化する 載せる情報 = 特定ビジネスや技術へのインデックス 紐づくドキュメント‧スクリプト Skill
28. コンテキスト管理のこれから 実例: コスト最適化スキル コスト管理‧削減の観点で、AWSのタグ付 けルールや各種スペック調整などのナレッ ジを蓄積したもの 簡単なインフラならAIに書かせてもそれなり に形になるが、初期のサービスには過剰な リソース割り当てになりがち よくある調整箇所をリストアップし、 費⽤対効果が⾼くなるように変更する service, product, ownerタグを付与する dev, stg環境なら夜間 はECS⽌める
29. コンテキスト管理のこれから 実例: tmuxコマンド送信スキル 弊社技術ブログ 「実装はClaude、レビューはCodex (作者 o8n)」より紹介 tmuxで別ペインでコマンドを送信するスキ ル シンプルながらこれを応⽤してClaude Code で実装‧CodexでレビューをさせるAIの協調 を実現 気になった⽅はぜひ弊社のzennへ
30. コンテキスト管理のこれから (Claude) Plugin Marketplace Skill, MCPなどの設定をgitリポジトリを通し て共有し、ClaudeCode向けに配布できる 統制のために必要な知識やコンテキストの 配布が抜群にやりやすくなった 最近 vercelから skills.sh というのもでてき た インフラスキル Plugin Marketplace アーキテクトスキル 経理スキル
31. コンテキスト管理のこれから PdM, Dev, QAなど業務知識やテクニックは スキルなどの仕組みを通して社内で公開‧ 発展していくことが推奨されるようになる （なりつつある） コンテキスト管理も個⼈‧チームから組織 にスケールしていく 組織固有のコンテキストをしっかり育てら れるかが今後のパフォーマンスの鍵になっ てくる そして... Dev PdM QA PdM Skills Plugin Marketplace Dev Skills QA Skills
32. コンテキスト管理のこれから After Product Dev PdM QA Future? Product Dev PdM QA PdM Skills Marketplace Dev Skills QA Skills
33. 少しだけ宣伝（1/2） 本⽇のスライドは公式Xで公開！ 開発チームの技術やイベントに関する情報を発信しています！ フォローお願いします！ 資料公開＆技術発信は公式Xから👇 @TOKIUM_Dev
34. 少しだけ宣伝（2/2） 34 🍣第3回 寿司ときLTナイト🍣 〜 エンジニア×PdM 越境のリアルな本⾳を語るLT会 〜 03/11(⽔) 19:30〜 @TOKIUM東銀座オフィス（東銀座駅徒歩3分） LTイベントやります🔥 詳細はこちら
35. エンジニアを募集しています！ 技術的チャレンジ • AIエージェントの群れを量産し、 多数のサービスとの連携を素早く実現する • AIエージェント実行制御を行う共通基盤の開発 する • 継続的に品質を上げる仕組みや、 セキュリティ・ガバナンス向上の仕組みを構築 一緒に挑戦してくれる仲間を募集してます！！ カジュアル⾯談実施中！ 現場のメンバーと気軽にお話しませんか？ 詳細はこちら
36. 株式会社TOKIUM 東 京 本 社 ｜ 〒104-0061 東京都中央区銀座 6 丁⽬18-2 野村不動産銀座ビル12階 ⻄⽇本営業所 ｜ 〒550-0015 ⼤阪府⼤阪市⻄区南堀江 1 丁⽬ 1 番14号 四ツ橋中埜ビル 7 階 36 URL : https://www.keihi.com/company