ALGO ARTISのLLM活用：あえて『摩擦』を残して会議で発言する実践的処方箋

• 事実と背景：ALGO ARTISのエンジニアが、LLMによる爆速開発と会議での発言不能という「理解の非対称性」の課題を提起。
• 技術的変革：Notion MCPやObsidian CLI、Gemini Notebookを駆使し、単なる要約ではなく「前提を積み上げる」メタプロンプティングを実践。
• 現場への影響：身につけたい能力に直結する「摩擦」をあえて残し、質問前の「3行メモ」を準備することで、主体的な議論への参加が可能に。

エンジニアの日常において、新しいプロジェクトや未知のドメインにアサインされた瞬間ほど、胃が痛むものはない。株式会社ALGO ARTISにジョインした筆者が直面したのは、まさに製造業のドメイン知識という巨大な壁だった。「購買計画」「発注点」「調達リードタイム」――個々の単語をググれば、辞書的な定義は1秒で手に入る。しかし、実際の会議室で繰り広げられるのは、「前工程が詰まっているから在庫から回そう」「いや、それでは来月の発注点を割り込む」といった、複雑に絡み合った利害関係と文脈の空中戦だ。単語の意味が分かっても、誰が何を懸念し、なぜその意思決定に反対しているのかという「文脈」が全く見えてこない。結果として、会議室の椅子を温めるだけの「ほかほかカイロ」と化してしまう。

この状況を打破すべく、我々エンジニアはLLMという銀の弾丸に頼りがちだ。筆者もNotion MCPを導入し、社内ドキュメントをClaude Desktopから横断検索できる環境を構築した。タスクの消化スピードは劇的に向上し、先輩から成果を褒められる。しかし、ここに恐ろしいデッドロックが潜んでいる。LLMが生成するなめらかで完璧な文章を読んでいる間は、あたかも自分がすべてを理解したかのような全能感に包まれる。だが、一歩画面を閉じ、いざ会議で「君はどう思う？」と振られた瞬間、頭の中は真っ白になり、自分の言葉では何一つ説明できないのだ。これは、LLMの出力という「他人の脳のキャッシュ」を、自分の「メインメモリ」にロードしたと錯覚しているに過ぎない。理解せずにEnterキーを叩き続ける開発スタイルは、いずれ重大なシステム障害を引き起こすスパゲッティコードを量産するのと同義であると、私は強い危機感を抱かざるを得ない。

この「理解したつもり」という無限ループから脱出するために、筆者が提示する実践的なアプローチが「あえて摩擦を残す」という設計思想だ。ここでいう摩擦とは、脳が汗をかく瞬間、すなわち「何も見ずに思い出す」「自分の言葉で言い換える」といった能動的な認知負荷を指す。

筆者は、LLMに「購買計画を分かりやすく説明して」と丸投げするのをやめた。代わりに、「この資料を理解するために、私は何を先に知る必要がありますか？」と問いかけ、前提知識を体系的に積み上げる「全体の地図」をLLMと共にビルドした。このメタプロンプティングの手法により、自分専用のカスタム教科書をローカルのObsidian上に構築する。Obsidian CLI（dev:domやdev:screenshot）を駆使し、ClaudeにHTMLの図をレンダリングさせながら視覚的な理解を補う。

しかし、真の「摩擦」はここからだ。筆者はこのデジタルな教科書をあえてPDFとして書き出し、タブレットとペンを使って「ここが分からない！」「LLMの説明がおかしいのでは？」と泥臭く書き込みを重ねた。さらに、Gemini Notebook（旧NotebookLM）にクイズを生成させ、画面を閉じた状態で記憶を想起するテストを繰り返した。これは、最新の認知科学における「アクティブリコール」の実践そのものである。

ここで、我々がLLMに「渡すべき仕事」と「渡してはならない仕事」の境界線を整理した以下の比較表を見てほしい。

資料の検索や構造化といった、身につけたい能力から遠い「無駄な摩擦」はLLMに100%アウトソースする。一方で、概念の言い換えや想起といった「身につけたい能力そのもの」に直結する「価値ある摩擦」は、絶対にLLMに渡してはならない。この一線を画すことで、LLMは我々の思考を奪う存在から、理解の往復回数を爆発的に増やす最強のブースターへと変貌するのだ。

なぜ、我々はここまで泥臭く「理解すること」に固執しなければならないのか。LLMの提案が常に正しく、タスクが予定通りに片付くのであれば、理解など不要ではないかという極論も存在する。しかし、私はその考え方に強く反対する。

第一に、LLMの提案を自分で評価できないエンジニアは、単に「LLMが提示した選択肢にEnterキーを押すだけのマシーン」に成り下がる。欠品リスクと在庫コストのトレードオフにおいて、LLMが「推奨はA案です」と出力したとき、その背景にあるビジネス上の泥臭い判断を理解していなければ、我々は自らの意思決定権を完全に放棄したことになる。第二に、理解を伴わない成果は、自分の仕事の価値を「伝聞」にしてしまう。周囲から「素晴らしい成果だ」と評価されても、自分自身が「なぜそれが良いのか」を実感できなければ、仕事の達成感はすべて他者からの伝聞となり、自己効力感は摩耗していく。LLMを使うほどタスクは高速化するのに、自分が「やった」という手応えが残らないという奇妙な非対称性。これこそが、現代のエンジニアが直面している精神的な危機の本質だ。

さらに、筆者は「人に聞くこと」もLLMに渡さなかった。ドキュメントに書かれていない「なぜこのアーキテクチャを選んだのか」「今何を優先しているのか」という泥臭いコンテキストは、LLMには絶対に答えられない。ただし、LLMを「質問の準備」に活用することは極めて有効だ。質問に行く前に、LLMと共に「1. ここまではこう理解している、2. 根拠は資料のこの部分、3. ここを確かめたい」という3行のメモを整理しておく。これにより、先輩エンジニアとの限られた時間で、より深い次元の議論が可能になる。

我々エンジニアは、明日からどう行動すべきか。まずは、自分が今日LLMに投げたプロンプトを振り返ってほしい。それは単なる「思考のサボり」か、それとも「理解を深めるための往復」か。LLMという強力な波に呑まれ、自らの思考の筋肉を退化させるのか、それとも「摩擦」をコントロールして自らの血肉とするのか。我々が今問われているのは、技術の効率性ではなく、「自分の仕事の時間を、どのように主体的に生きたいか」という、エンジニアとしての実存的な問いそのものである。