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

by Mulyu

Slide 1

Slide 1 text

　 1 AIによる開発の⺠主化を⽀えるコンテキスト管理のこれまでとこれから 2026年02⽉09⽇株式会社TOKIUM プロダクト本部横断チーム統括部東優太

Slide 2

Slide 2 text

自己紹介 & 会社概要 2

Slide 3

Slide 3 text

⾃⼰紹介プロダクト本部横断チーム統括部イネーブリング東優太 Yuta Higashi 経歴ネット広告会社のエンジニアとして初期のキャリアを経験後、2020年に沖縄移住とともにTOKIUMに参加 2023年にイネーブリングチームに異動し、全体の⽣産性向上に注⼒ 2025年6⽉にはAgentSDKチームとしてAI開発を補助‧促進興味領域 Scala / Ruby / DDD / Scrum

Slide 4

Slide 4 text

会社名設⽴⽇所在地従業員数代表取締役株式会社TOKIUM 2012年 6⽉ 26⽇東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 約240名 (2025年12⽉、正社員のみ) 黒﨑賢⼀ 4 会社紹介

Slide 5

Slide 5 text

「経理AIエージェントTOKIUM」とは 5 経理AIエージェント「TOKIUM」は、AIとプロスタッフが連携し、経理作業を丸ごと代⾏。単に効率化するのではなく、作業⾃体を⼿放すことで「時を⽣み」、全社員が本来の業務に集中できる環境を実現。

Slide 6

Slide 6 text

⽣成AIは開発そのものを変えてしまった

Slide 7

Slide 7 text

⽣成AIは開発そのものを変えてしまった Product Dev PdM QA Before Product Dev PdM QA After

Slide 8

Slide 8 text

⽣成AIは開発そのものを変えてしまった誰でもプロダクトへ貢献できるようになった⽣産量が簡単に向上するようになった無秩序なコードが⾶び交うようになった品質が簡単に低下するようになったしかし

Slide 9

Slide 9 text

⽣成AIは開発そのものを変えてしまったユーザーに投稿機能を実装してサーバー‧クライアントの2構成ですバックエンドはGo&Ginで Port&Adapterを採⽤していますクライアントはTS&Reactで Feature-Sliced Designを採⽤しています機能実装時にはユースケース図 -> API仕様 -> 実装の順に進めますプルリクエストにはチケット番号とfeature or bugのラベルを付けます期待したコードを引き出せるか？開発プロセスに沿っているか？管理ルールに従っているか？⽣成AIの性能を引き出すためには、適切なコンテキストを与えることが必要不可⽋コンテキスト

Slide 10

Slide 10 text

生成AIとうまく付き合うために、コンテキスト管理に向き合おう

Slide 11

Slide 11 text

コンテキスト管理のこれまで

Slide 12

Slide 12 text

コンテキスト管理のこれまで「こういう⾵に考えさせるとうまくいく」といったプラクティスが探索され、様々なプロンプトが社内でやり取りされた管理されるというほどのものはなく、ドキュメントやチャットツールで共有される TOKIUMにおいては、むしろ開発者以外での活発な共有が⾏われていた黎明期: Prompt あなたはGASの開発者ですスプレッドシートに定期的に書き込むプログラムを作成してください … 下記の⽂章を整理してください誤字脱字を修正してください表現をですます⼝調に直して... Prompt Prompt

Slide 13

Slide 13 text

コンテキスト管理のこれまで READMEに書かれるような設計ドキュメントの流⽤から始まり、AIに知識を伝えることが本格化し始めたアーキテクチャやコーディング規約など、たくさんの情報をなるべく詰め込むツールを導⼊するたびに、サポートするファイル配置が異なり、 1リポジトリの中でも管理に四苦⼋苦するバックエンドはDDD, Port&Adapterアーキテクチャです CLAUDE.md バックエンドはDDD, Port&Adapterアーキテクチャです AGENTS.md バックエンドはDDD, Port&Adapterアーキテクチャです Knowledge 初期:Memory(Custom Instruction)

Slide 14

Slide 14 text

コンテキスト管理のこれまで設計や実装を経て変わっていくドキュメントをAIの⼊⼒‧出⼒両⽅に設定し、メンテナンスを⾃動化する⽅向へドメインモデリングやユースケース駆動など、設計のプロセスにAIを組み込んでみた⼩さなうちは問題なかったものの、プロダクトとドキュメントの拡張に伴って⼆重管理に苦しむようになる中期:Document ユーザーの投稿機能を実装してバックエンドはDDD, Port&Adapterアーキテクチャで、ドメインモデルは model.mdです # model.md 投稿: タイトル‧説明⽂と投稿者を持ったデータです Document

Slide 15

Slide 15 text

コンテキスト管理のこれまでコードレビュー‧プルリクエストの作成... 個⼈でもチームでも、頻出する使い⽅をコマンドとし、細かな業務改善が進んだ MCPのPrompts機能は、カスタムコマンドとして配布できることを発⾒し、社内ライブラリのセットアップなどをMCP化コンテキストを配布可能に後期:Command, MCP /tokium-setup MCP Server /tokium-update /tokium-oauth /tokium-template-server

Slide 16

Slide 16 text

何をどうやってコンテキストに載せるべきか

Slide 17

Slide 17 text

何をどうやってコンテキストに載せるべきか AIに作業をしてもらうときに、考慮してもらいたいことはあまりに多い「テスト通るまで修正して」「仕様書はこのフォーマットで書いて」「コードはここに配置して」「残作業でTODOリスト作って」「インフラ作るなら稟議必要ね」「ブランチは feat/チケットで」

Slide 18

Slide 18 text

何をどうやってコンテキストに載せるべきかコンテキスト上限が存在するため、全部読み込んで考慮させることはできないし、たくさん読み込むと遅すぎるユースケースに応じて、必要なコンテキストだけを読み込む必要がある

Slide 19

Slide 19 text

何をどうやってコンテキストに載せるべきかスコープ安定性⾼低⼩⼤安定性とスコープの2軸で考えてみる安定性: 与える情報は変動的か‧固定的かスコープ: 与える情報は固有か‧⼀般か

Slide 20

Slide 20 text

何をどうやってコンテキストに載せるべきかスコープ安定性⾼低⼩⼤低安定性‧⼩スコープ = Prompt 「○○の機能を実装して」「○○のコードをリファクタリングして」載せる情報 = 達成したいこと Prompt

Slide 21

Slide 21 text

何をどうやってコンテキストに載せるべきかスコープ安定性⾼低⼩⼤⾼安定性‧⼩スコープ = Command 特定の⽬的を達成するための⼿順「要件定義は下記の⼿順で進⾏」「リファクタリングはまずテストを書く」載せる情報 = 設計や実装などのプロセス Document Command

Slide 22

Slide 22 text

何をどうやってコンテキストに載せるべきかスコープ安定性⾼低⼩⼤低安定性‧⼤スコープ = Document プロダクトの進歩に伴って適宜更新しながら、必要な時だけ引き出したい知識「名前が重複した時はエラーを出⼒」「api/departmentsで部署⼀覧API」載せる情報 = プロダクトの仕様や設計書 Document

Slide 23

Slide 23 text

何をどうやってコンテキストに載せるべきかスコープ安定性⾼低⼩⼤⾼安定性‧⼤スコープ = Memory プロダクトやシステム固有の常に意識したい情報「ヘキサゴナルアーキテクチャに沿う」「コンテナはこのコマンドで起動」載せる情報 = アーキテクチャや慣例 Memory

Slide 24

Slide 24 text

何をどうやってコンテキストに載せるべきかスコープ⼩⼤安定性⾼低 Technical Context Business Context なにから整備に⼿を付けるべきか？コンテキストはビジネス‧テクニカルの分類に応じておよそ特性が決まってくると考えている技術構造は安定的でビジネス要求は不安定安定させやすいテクニカルコンテキストから整備し、不安定なビジネスコンテキストは軽量な⽀援から進めていくと良い

Slide 25

Slide 25 text

コンテキスト管理のこれから

Slide 26

Slide 26 text

コンテキスト管理のこれから Skill 特定の業務に関する知識や⼿順をパッケージ化 AI起動時に説明⽂のみを読み込み、必要になってから全⽂‧リファレンスなど段階的に読み込む 2025年12⽉にAgentSkillとして標準化された現在要件定義‧仕様策定の知識を備え設計を⽀援します Skill ユーザーの投稿機能を実装してセキュリティポリシーを備えコードレビューを⽀援します

Slide 27

Slide 27 text

コンテキスト管理のこれからスコープ安定性⾼低⼩⼤ Skill 説明⽂からドキュメントへ、段階的に読み込めるので、スコープと安定性が動的に変化する載せる情報 = 特定ビジネスや技術へのインデックス紐づくドキュメント‧スクリプト Skill

Slide 28

Slide 28 text

コンテキスト管理のこれから実例: コスト最適化スキルコスト管理‧削減の観点で、AWSのタグ付けルールや各種スペック調整などのナレッジを蓄積したもの簡単なインフラならAIに書かせてもそれなりに形になるが、初期のサービスには過剰なリソース割り当てになりがちよくある調整箇所をリストアップし、費⽤対効果が⾼くなるように変更する service, product, ownerタグを付与する dev, stg環境なら夜間はECS⽌める

Slide 29

Slide 29 text

コンテキスト管理のこれから実例: tmuxコマンド送信スキル弊社技術ブログ「実装はClaude、レビューはCodex (作者 o8n)」より紹介 tmuxで別ペインでコマンドを送信するスキルシンプルながらこれを応⽤してClaude Code で実装‧CodexでレビューをさせるAIの協調を実現気になった⽅はぜひ弊社のzennへ

Slide 30

Slide 30 text

コンテキスト管理のこれから (Claude) Plugin Marketplace Skill, MCPなどの設定をgitリポジトリを通して共有し、ClaudeCode向けに配布できる統制のために必要な知識やコンテキストの配布が抜群にやりやすくなった最近 vercelから skills.sh というのもでてきたインフラスキル Plugin Marketplace アーキテクトスキル経理スキル

Slide 31

Slide 31 text

コンテキスト管理のこれから PdM, Dev, QAなど業務知識やテクニックはスキルなどの仕組みを通して社内で公開‧ 発展していくことが推奨されるようになる（なりつつある）コンテキスト管理も個⼈‧チームから組織にスケールしていく組織固有のコンテキストをしっかり育てられるかが今後のパフォーマンスの鍵になってくるそして... Dev PdM QA PdM Skills Plugin Marketplace Dev Skills QA Skills

Slide 32

Slide 32 text

コンテキスト管理のこれから After Product Dev PdM QA Future? Product Dev PdM QA PdM Skills Marketplace Dev Skills QA Skills

Slide 33

Slide 33 text

少しだけ宣伝（1/2）本⽇のスライドは公式Xで公開！開発チームの技術やイベントに関する情報を発信しています！フォローお願いします！資料公開＆技術発信は公式Xから👇 @TOKIUM_Dev

Slide 34

Slide 34 text

少しだけ宣伝（2/2） 34 🍣第3回寿司ときLTナイト🍣 〜エンジニア×PdM 越境のリアルな本⾳を語るLT会〜 03/11(⽔) 19:30〜 @TOKIUM東銀座オフィス（東銀座駅徒歩3分） LTイベントやります🔥 詳細はこちら

Slide 35

Slide 35 text

エンジニアを募集しています！技術的チャレンジ ● AIエージェントの群れを量産し、多数のサービスとの連携を素早く実現する ● AIエージェント実行制御を行う共通基盤の開発する ● 継続的に品質を上げる仕組みや、セキュリティ・ガバナンス向上の仕組みを構築一緒に挑戦してくれる仲間を募集してます！！カジュアル⾯談実施中！現場のメンバーと気軽にお話しませんか？詳細はこちら

Slide 36

Slide 36 text

株式会社TOKIUM 東京本社｜〒104-0061 東京都中央区銀座 6 丁⽬18-2 野村不動産銀座ビル12階⻄⽇本営業所｜〒550-0015 ⼤阪府⼤阪市⻄区南堀江 1 丁⽬ 1 番14号四ツ橋中埜ビル 7 階 36 URL : https://www.keihi.com/company