案件に一番詳しいAIを Amazon Bedrock AgentCore で作る ― 知見が知見を生むチームへ / Compounding Knowledge with AgentCore

2026年8月12日、NRIネットコム社内勉強会「Tech and Design Study」での発表資料です。（ユースケのユースケース Case9 / #nncstudy）

チームにAIツールを配っても、案件の知見までは配られません。同じ「この設計をレビューして」でも、案件を知っている人ほど前提を添えられるので、返ってくるものが変わります。差を作っているのはAIではなく、入力に乗った案件知識です。

案件の知見をAIが読める形で貯め、使い、学びを書き戻す「知見の複利」を軸に、Amazon Bedrock AgentCore / Amazon Bedrock Knowledge Bases / Slack で「案件に一番詳しいAI」を作る構成を扱います。

- AIは配ったが、案件の知見は配られていない（DORA 2025）
- 知見の複利 ― 蓄積なし / 単利 / 複利 の3類型と、回り続ける3条件
- 詳しさ ＝ 広さ × 確かさ。技術が「可能にする」ものと、運用が「育てる」もの
- 構成と、知見が正本に入る経路
- なぜ各自の Claude Code ではなく、共用エージェントを Slack に置くのか
- 複利が回った先の歪みと、判断を人に残す3段階の権限設計

デモで使っているデータは完全に架空の案件です。実在の顧客名・案件名は含みません。

Transcript

1. NRIネットコム TECH AND DESIGN STUDY ユースケのユースケース Case9 知見が知見を生むチームへ 案件に一番詳しいAIをAgentCoreで作る 志水 友輔 NRIネットコム株式会社 2026年8月12日
2. あの人に聞けば、だいたい分かった。 その人は、もうこのチームにいない。 過去の経緯も、書かれていない制約も、 その人の頭の中にありました。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 1
3. NRIネットコム株式会社 / Cloud Architect 志水 友輔（しみず ゆうすけ） アーキテクト・AI活用推進・人材育成 Japan AWS Ambassadors（2023-26） AWS CDK / Bedrock AgentCore / カメラ / つけ麺 息子が負けるの嫌すぎて、 「負けたら勝ちゲーム」という新ルールを作ってきた Blog: #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 2
4. ① 課題提起 配ったのに、バラつく AIツールは、すでにチーム全員に配られている。それでも、こうなる。 01 02 03 プロンプトのばらつき AIは案件を知らない やりとりが残らない 同じ依頼をしても、人によって出てくるものが 足りない前提を、聞く人が毎回自分で埋 埋めた前提も、返ってきた答えも、その場で 違う。 めている。 消える。 01 は多くの人が感じている。今日話したいのは 02 と 03。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 3
5. ① 課題提起 AIは案件を知らない。足りない前提は、聞く人が埋めている 新しく入った人 ベテラン 設計書だけを渡す 設計書 ＋ 前提を添える ・書かれていない制約を知らない ・去年この構成にした理由 ・過去の経緯を知らない ・この案件特有の制約 ・返ってくるのは一般論 ・返ってくるのは案件の答え 返ってくるものの差は、AIの差ではなく添えた前提の差。 AIを配っても、この差は埋まらない。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 4
6. ① 課題提起 補った前提は、どこにも残らない 90% 補った前提も、返ってきた答えも、チャット履歴に消える 案件知識は、人の頭とスレッドに散在する AIを使っている技術者の割合。 それでも、デリバリの安定性は上がっていない。 （DORA 2025・Google／技術者 約5,000人） DORA 2025 新しく入った人のキャッチアップに、数週間〜数ヶ月 AIはチームを直さない。既にあるものを増幅する。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 5
7. ② 知見の複利 知見の複利 ― 知見が、知見を生む STEP 1 STEP 2 STEP 3 STEP 4 元本 利息 再投資 元本が増える AIが読める形で貯めた その知見を入力に、AIが 成果から得た学びを、 次の出力が、さらに良くなる チームの知見 出すより速く・良い成果 また知見に書き戻す ― そしてまた回る 鍵は「貯める」ことではなく「回す」こと。回すほど元本が増え、次の出力がさらに良くなる。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 6
8. ② 知見の複利 貯めるだけは単利、戻して回すと複利 知見量 蓄積なし → 横ばい 複利 20 個人の頭とチャット履歴に消える 15 単利 → 線形 Wikiや議事録に残るが、人が探して読む 複利 → 指数 単利 10 5 AIが読める形で残り、次のタスクで使われ、使うたび更新され る 蓄積なし 0 0 1 2 3 4 5 6 7 8 9 10 時間 分かれ目は人数ではなく「ループを回すか」。個人でも、戻して再投資すれば複利は回る。 ただし序盤の数ヶ月は単利の方が速く見える。交差点を越える前に止めてしまうのが、いちばん多い失敗。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 7
9. ② 知見の複利 なぜ「人が読む」と「AIが読む」で分かれるのか 形式知が仕事に効くには、これまで「誰かが内面化する」必要があった（SECI・野中 1995） これまで ― 内面化が先 いま ― 内面化が後 読んで身につけてから、効く 効いてから、身につく ・読む時間がかかる ・知らない人の成果物でも変わる ・読んだ人にしか効かない ・全員の出力に同時に乗る ・異動・退職で消える ・人が変わっても残る 内面化は無くなっていない。順番が入れ替わった。 「その人が知っているか」が、成果物が変わる条件ではなくなった。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 8
10. ② 知見の複利 回す3条件 ― どれが欠けても止まる 01 02 03 外部化 再投資 書き戻し AIが直接読める形で、知見が存在する。 その知見が、次のAIタスクの入力として実 成果から学びを抽出し、知見ベースを更新 際に使われる。 する工程がある。 よくあるのは 01 だけやって止まるパターン。 書いた時点で満足し、次のタスクで参照されない ＝ 単利のまま。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 9
11. ③ 詳しさの正体 詳しさ ＝ 広さ × 確かさ Coverage Fidelity 広さ ― 何を知っているか 確かさ ― どれだけ効くか ・観点：事実／理由・経緯／手順／関係 × ・最新であること ・明示知：ドキュメントに書けるもの ・必要なときに引き当てられること ・暗黙知：書かれていない制約・地雷 ・根拠を示せること／矛盾しないこと 全部載っていても古ければ詳しくない。最新でも浅ければ詳しくない。 一番効くのは暗黙知。ここを拾えるかで「物知り」と「本当に詳しい」が分かれる。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 10
12. ③ 詳しさの正体 どこまでが技術で、どこからが運用か 技術が"可能にする" 複利と運用が"育てる" 買える ― 導入した日から動く 買えない ― 回した時間しか埋めない ・知識の取り込み ・暗黙知の明示化 ・検索と引き当て ・最新であり続けること ・引用と根拠の提示 ・矛盾がないこと ・バージョン管理 ・何を捨てるかの判断（剪定） 経路依存 ― 後発は、同じ製品を買ってもコピーでは追いつけない。同じ時間を回すしかない。 詳しさは買えない。回した分だけ育つ。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 11
13. ③ 詳しさの正体 広さと確かさを、AgentCore でどう組むか 読む経路 Retrieve Slack API GW ＋ Lambda AgentCore Runtime Gateway ＋ ツール 「覚える」は複利ではない。 Memory が持つのは 正本 AgentCore Memory Amazon Bedrock 短期の会話文脈だけ。 Knowledge Bases 書く経路 ＋ Amazon S3 人が書く Git（PR） CI（形式を検査） 取り込み （Ingestion） 5ページ目でベテランが手で添えていた前提を、この経路が代わりに添える。誰が聞いても同じ前提が付く。 ただし、知見ベースに書かれていれば の話。部品が担うのは「広さ」と「引き当て」まで ― 暗黙知の明示化と最新性は、この図の外 ＝ 運用にある。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 12
14. ③ 詳しさの正体 知見はどうやって、正本に入るのか 読む経路 Retrieve Slack API GW ＋ Lambda AgentCore Runtime Gateway ＋ ツール Gateway のツールとして AgentCore Memory エージェントが起案する 正本 Amazon Bedrock Knowledge Bases 書く経路 ＋ Amazon S3 人が書く Git（PR） CI（形式を検査） 取り込み （Ingestion） エージェントが書けるのは提案まで。正本を変えるのは、人のマージだけ。 ②の「書き戻し」が物理的に起きる場所。起案は仕組みにできるが、「これは知見だ」と認める判断は人に残る。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 13
15. ④ デモ デモの前提 ― 架空案件「KAI」 デモは、こういう案件を想定して作っています。 01 02 何を作っている案件か チームの状況 BtoB 向け在庫管理 SaaS の刷新。レガシー基盤を AWS でモダ PM・設計/開発・SRE の6人が、2025年6月から1年がかりで動 ナイズしています。設計の分岐が多く、選ばなかった方の理由が いている案件。途中で方針を決め直した設計もあります。 後から効いてくるタイプです。 見てほしいのは、答えの賢さではなく、どの決定を引いて答えているか。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 14
16. ⑤ なぜ Slack に置くのか それ、Claude Code でよくないですか？ まず Claude Code 方式をやるべき。正本を Git に置けば、それだけで複利は回り始める。 各自の Claude Code 共用エージェント 端末の中で完結する 全員がいる場所に置く ・呼べるのは、端末の中だけ ・すでに全員がいる Slack から ・権限は、使う人の権限そのもの ・エージェント固有の権限を引ける ・やりとりも学びも本人の中で終わる ・やりとりがチャネルに残る 差は、検索の賢さではない。 どこから呼べて、誰に何を許すか。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 15
17. ⑤ なぜ Slack に置くのか Git は分岐を防ぐ。でも「上げない」は防げない 01 02 03 個人の環境に溜まる 複数リポジトリに散る そもそも上げられない ~/.claude/CLAUDE.md や インフラ側とアプリ側が別なら、同じ知識が 手元で解決した知見は、正本に上げる一 CLAUDE.local.md に書いた案件知識は、 別々の CLAUDE.md に別々の粒度で書 手間を踏まなければ本人の中で完結する。 誰にも共有されない。 かれる。 正本は1つでも、上がらなかった知見が各自に沈殿する。 本質は「分岐するか」ではなく、「共有がデフォルトか、追加作業か」。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 16
18. ⑤ なぜ Slack に置くのか 同じ複利が、器の大きさで2本 個人の器（Claude Code） 案件の器（共用エージェント） 立ち上がりが速い 仕込みが要る ・今日から回せる ・正本が1つに集まる ・上げなかった知見は沈殿する ・何が引かれたか観測できる ・本人が抜けたら消える ・権限を設計できる ・権限を分けられない ・抜けても消えない 順序は、まず個人の器で回す → 元本と人が増えたら案件の器に移す。 エージェントは複利の発生源ではなく、器を大きくする装置。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 17
19. ⑥ 新しい歪みと、判断の線引き 複利が回った先に出てくる、2つの歪み 01 02 人間が追いつけない 負の複利 ボトルネックは「AIが遅い」ではなく、「人が追いつけないほど 間違った知見も、同じ勢いで増幅される。だから書き戻しに 速い」に移る。レビューと合意が律速になる。 検証を挟み、定期的に剪定する。 剪定するには「何が引かれたか」の観測が要る。 共用の入口に集めたことの副産物であり、①で見た「増幅する」の裏側でもある。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 18
20. ⑥ 新しい歪みと、判断の線引き 判断は人 ― 3段階の権限設計 LEVEL 1 LEVEL 2 LEVEL 3 事実提示 定型の実行 新規・高影響 トレードオフ 過去の decision を引く、 既定のルールの中で 前例がない、影響が大きい、 根拠を示す 決まった作業をする 利害がぶつかる → エージェント → エージェント →人 「全部人が見る」は逃げで、エージェントの価値も消える。線を引くから任せられる。 この3段階は、共用エージェントだから構造で引ける。各自の端末では運用ルール（お願い）にしかならない。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 19
21. ⑦ まとめ 明日から始める、最小のループ 01 知見の置き場所を1つ決める 02 「完了の定義」に書き戻しを入れる 測り方は、量ではなく3指標 Time-to-Context 新しく入った人が立ち上がるまでの時間 03 次のタスクで必ず参照する 再発指摘率 04 月に1回、剪定する 一発合格率 人に残すのは判断 同じ指摘が何回くり返されるか AIの出力がそのまま通る割合 書き戻しをどこまで仕組みにしても、最後の「これは知見だ」は人に残す。 ⑥で引いた「判断は人」の線が、ここにももう一本。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 20
22. ご清聴ありがとうございました。 資料は Speaker Deck で公開します。 #nncstudy Copyright（C） NRI Netcom, Ltd. All rights reserved. 21