境界での検証：外部に触れるすべてのもの

1. So What?

ある時から自分の返信ドラフトを見ながら、一言が頻繁に浮かんだ。"So What?"

マーチャントの立場でこの返信を受け取ったら、次に何をすればいいのか。技術的には正確だが アクションがない返信。原因は分析したがマーチャントは何も始められない返信。それが So What が浮かぶ返信だった。

「受け取り手のドメイン言語」という抽象表現がある。結局はマーチャントの目線に合わせる という意味だ。自分はそこを重点的に掘り下げた。返信の最後の一行に 「あなたはこういう状況にあり、次に X をしてください」 を加える。その一行が返信の重みを変えるのを見た。

この思考はマーチャント返信で止まらなかった。Ops SC、JIRA エスカレーション、マネージャー へのハンドオフ — 受け取り手が異なるドメイン言語を使うほど、より精密でなければ ならなかった。結局 check_response の tone calibration ルール — 受信者が 誰かによって語彙と構造を別々に検査する — も、同じ思考から生まれた。

2. 検索アシスタントは始まりであって結論ではない

2026-05-02。社内 RAG ベースの検索アシスタントが作った検索結果の要約の上に、別の LLM(ollama)を重ねてもう一度要約しようとする試みが自分の手にあった。

よく考えると答えは明瞭だった。検索アシスタントは調査の始まりを告げるツールだ。 過去のすべてのデータをサーチして一掴み渡してくれれば、そこから JIRA と Confluence MCP で一つずつ全部 Fetch して真偽を把握すること — それが既に最も最適化された流れだった。 ollama でもう一度要約することは、合成された虚偽を作る道であって、結論を強化する道では なかった。

いろいろ試した末の認定だ。一つの効果のないアイデアを諦めながら知ったのは、ツールごとに 自分の場所があるということ。検索アシスタントは出発点、MCP fetch は検証、結論の引用は1次 出典から。これを gate_source_fetch.sh hook で体系化した — 返信段階に入る 前に、アシスタントが引用した JIRA / Confluence / URL が本文 fetch まで至っていなければ 遮断する。