Copyright © NIFTY Corporation All Rights Reserved. 「なぜそう決めたのか」を残し続ける仕組み Notion AI カスタムエージェント × Slack連携による設計判断の自動記録 小林 雅幸 ニフティ株式会社 

Copyright © NIFTY Corporation All Rights Reserved. 自己紹介 2 小林 雅幸 担当業務 @nifty光、@nifty with ドコモ光 などの接続サービスの開発/運用 kobayashi masayuki 趣味 スノボ、写真撮影、配信視聴 

Copyright © NIFTY Corporation All Rights Reserved. 今回作った成果物の全体像 3 ざっくり構成図（後で詳細なスライドを説明します） Slack上のスレッドで議論が進んでいるところに、メンションでNotion AI カスタムエージェントを呼び出し Notion AIは、その会話の中から意思決定にあたる情報を抽出し、背景・判断・理由が分かる形に整理 それをADR DBに蓄積することで、「何を決めたか」「なぜそう決めたか」を後から見返せるように 最後に、蓄積したADRはNotion AIで検索・参照し、人が設計判断の確認に活用できるように 

Copyright © NIFTY Corporation All Rights Reserved. 背景：開発現場で起きていたこと 4 意思決定の分散 複数人・複数テーマで仕様判断が並行して進む 仕様ヒアリングやQAでの決定事項・レビューの判断結果などがSlack、Notionに情報が散る 

Copyright © NIFTY Corporation All Rights Reserved. 課題：意思決定が分散すると何が困るか 5 逆引き調査コストが大きい 判断の文脈を追いにくい AIによる調査結果を信頼しにくい 過去の決定事項を確認する際に、SlackやNotionを都度遡る必要がある 関係者が関連するスレッド・資料・コメントを探し直し、内容を読み解くため、確認に時間がかかる Slackの複数スレッドやNotion上の資料に分散していると、誰が・何を・なぜ・どのように決めたかが追いにくい 特に1つのスレッド内で複数の決定事項が並行している場合、どの発言がどの判断に紐づくのかを読み解く必要がある Notion AIを利用できる環境であっても、関連性の低い情報が多いと、必要な意思決定に正しくたどり着きにくい 情報が整理されていない状態では、AIの回答に不要な情報が混ざり、調査結果の信頼性が下がる。 

Copyright © NIFTY Corporation All Rights Reserved. 課題解消に向けたアプローチ 6 ADR（Architecture Decision Record） ソフトウェアやシステムにおける重要な意思決定の内容、背景、経緯を文書化するための手法 　意思決定を記録するArchitecture Decision Record (ADR)の話（ https://engineering.nifty.co.jp/blog/23151 ） 👉ADRに関するブログ（NIFTY engineering） 「何を決めたか」だけではなく、「なぜそう決めたのか」まで残す 記録する情報（例） ・背景：どんな課題・制約があったか ・決定：何を選んだか ・理由：なぜその判断にしたか ・影響：どこに影響するか ・状態：検討中 / 決定済み / 廃止 後から見た人が同じ議論を繰り返さないような情報を残す 

Copyright © NIFTY Corporation All Rights Reserved. ADRにおける課題 7 書き続けるのが難しい 人があとから整理・転記する必要がある 開発や対応を優先すると、記録作業の優先度が下がる 結論だけ残り、背景や理由が抜けやすい 人によって記録の粒度にばらつきがある 記録する項目は同じでも、内容の深さが揃わない どこまで書くべきかの判断が人に依存する 忙しいと最低限のメモになり、後から読み返すには情報が足りない 

Copyright © NIFTY Corporation All Rights Reserved. 目指した状態 8 自動で書き続ける仕組みであること 普段の業務導線から使えること 決まったフォーマットでADRを記載出来ること 人があとから探して転記しなくてよい 記録の粒度や書き方のばらつきを抑える 普段使っているSlack / Notionの流れで使えるようにする 新しい入力作業を増やさない 後から見ても判断経緯を理解しやすくする 継続的に意思決定が蓄積される 

Copyright © NIFTY Corporation All Rights Reserved. 成果物：Notion AIカスタムエージェント × Slack連携 9 

Copyright © NIFTY Corporation All Rights Reserved. なぜ◯◯なのか 10 なぜSlack起点なのか なぜNotion AIカスタムエージェントにしたか 最終的な議論や結論が、ほぼSlack上に文章として残るようになっている 新しい入力画面を増やさず、普段のSlack上の流れで起動できるため、利用者の負担が少ない 普段から使っているドキュメント管理基盤であるNotionDBに簡単に蓄積できる 判断基準をInstructionsとして明文化できるため、他の人もルールを確認でき、説明可能性を高められる 日次実行・メンション起動など、運用に組み込みやすい ・チームのやり方で、毎日「共有したいこと」リマインドが飛び、決まったことや議論したいことが記載される ・デイリー等で会話した後、起案者が結局どうなったかを記載する流れ コード不要で構築・調整でき、メンテナンスしやすい 

Copyright © NIFTY Corporation All Rights Reserved. ADRとして残している内容 11 Notion DB プロパティ一覧 ステータス 自動設定 ・Draft：検討中・未確定 ・Accepted：合意済み・有効 ・Rejected：不採用 ・Deprecated：現在は使われなくなった判断 ・Superseded：新方針に置き換え済み ADRの状態を表す項目 背景・問題 何を解決するための決定かを1〜3文で書く 議論の経緯 選択肢、主要論点、判断理由を簡潔に書く 

Copyright © NIFTY Corporation All Rights Reserved. 動作例：Slackの議論がADRに変わるまで（議論） 12 Slack上の議論 Aさん： 新しい問い合わせフォームから来た内容は、 担当チームに直接通知する形でよいでしょうか。 Bさん： 直接通知だけだと、対応状況が追いにくくなりそう です。 まず一覧で管理できる場所に集約した方がよいと思います。 Cさん： 対応漏れを防ぐため に、受付後は 管理リストに登録 し、担当者とステータスを更新できる形がよさそうです。 Aさん： たしかに対応状況を追える方が安全ですね。 では、問い合わせは管理リストに集約し、担当者とステータスを管理する方針で決定とさせていただきます。 ※例（AIによる生成、社内情報とは関連なし） 

Copyright © NIFTY Corporation All Rights Reserved. 動作例：Slackの議論がADRに変わるまで（登録） 13 ADR DBへの登録例 タイトル：問い合わせ内容を管理リストに集約して対応状況を管理する ステータス：Accepted カテゴリ：運用設計 対象システム/機能：問い合わせ対応フロー 背景・問題：問い合わせ内容を担当チームへ直接通知するだけでは、対応状況や対応漏れを後から確認 しづらい懸念があった。 議論の経緯：直接通知する案と、管理リストに集約する案が検討された。 対応状況の可視化と対応漏れ防 止を優先し、管理リストで担当者とステータスを管理する方針になった。 決定内容：問い合わせ内容は管理リストに集約し、担当者とステータスを管理する。 決定日：2026-06-08, 関連Slack/URL：Slackスレッド ※例（AIによる生成、社内情報とは関連なし） 

Copyright © NIFTY Corporation All Rights Reserved. 効果：定性的なメリット 14 情報探索の負荷を下げる 意思決定の背景を共有しやすくする 判断の抜け漏れを防ぐ Slackを遡って過去の会話を探さなくても、ADRを見ることで決定事項や判断経緯を確認できる。 Notion AIの要約により、決定内容を短い文章で把握できるため、必要な情報にたどり着くまでの時間を減らせる ADRとして判断理由や前提を残すことで、「なぜその決定になったのか」をチーム内で共有しやすくなる 休暇中や不在時に行われた決定も追いやすくなり、後から参加したメンバーでも背景を理解しやすい Draftに未決定の内容を残しておくことで、必要な意思決定を後から見返せる 個人の記憶に頼らず、レビュー時や再検討時に判断の抜け漏れを防ぎやすくなる 

Copyright © NIFTY Corporation All Rights Reserved. 効果：定量的なメリット 15 ADR蓄積量 約12週間で227件のADRを蓄積 ・日々の議論から、週平均約19件の判断内容を記録 社内アンケート：時間削減感 社内アンケートでは、週あたり数10分〜数時間規模の削減感 ・主に削減された作業は次のスライドに記載 1件あたり手動登録にかかる時間を10分/件と想定すると、約37.8時間の削減に ・決定内容を要約する ・背景・問題を整理する ・議論の経緯を書く ・ステータスを判断する ・関連URLを貼る... 

Copyright © NIFTY Corporation All Rights Reserved. 社内アンケート結果：効果 16 主な利用目的は「過去判断の確認」 ・単なる記録ではなく、過去の判断理由を確認するために使われている Slackを探し直す作業の削減につながっている ・Slack検索・スレッド読み返し・過去判断確認 が減っている 

Copyright © NIFTY Corporation All Rights Reserved. 社内アンケート結果：課題 17 評価は前向き。ただし改善前提 ・明確に否定的な回答はなく、有用性または改善余地込みの有用性を感じている 量の増加に伴い「検索性」と「情報の信頼性」が次の課題に ・単に「記録を残す」段階はクリア。 ・今後は、増えた記録をどう探し、どう正確性を担保し、どう更新していくかという運用体制へのシフトが必要 

Copyright © NIFTY Corporation All Rights Reserved. 導入後に見えてきた課題 18 DraftからAcceptedへの更新漏れ 蓄積後に探しやすくする工夫が必要 内容の正確性・信憑性に不安が残り、再確認の手間が発生 会話スレッドが別で進行することが多く、正確な結論とDraftとの紐づけが完全に出来ない場合がある 蓄積するだけでは、必要なときに使いづらい。 分類・タイトル・検索導線の整備が必要である ドキュメントを見つけても「情報が正しいか」の確証が持てないケースがあり、 最終的に詳しい人へのヒアリングが必要になるため、検索後の確認コストが生じている。 古い情報の整備 過去の決定が上書きされた場合、Deprecated / Superseded として管理する必要がある 

Copyright © NIFTY Corporation All Rights Reserved. 今後やりたいこと 19 AIによるメンテナンス候補の提示 判断が必要な場面でAIが先回りしてADRを参照する Draftのまま残っているADR、Acceptedへ更新できそうなADR、重複・類似しているADR、古くなっている可能性 があるADRをAIが検出 人はADRを全件読むのではなく、AIが提示した候補を確認し、ステータス更新や整理の最終判断だけを行う レビュー依頼や設計変更のタイミングで、関連するADRを自動で検索する 過去の決定内容・背景・判断理由と照らし合わせ、 既存方針と矛盾していないかを確認する 必要に応じて、新しい判断を既存ADRの更新・置き換え候補として提示する 

Copyright © NIFTY Corporation All Rights Reserved.