はじめに
「議事録も実験結果も仮説もタスクも、全部Markdownにしてエージェントと一緒に育てる」──そんな運用が、松尾研究所では半分以上のプロジェクトにすでに入っているそうです。
2026年8月20日に開催された松尾研究所の勉強会「松尾研究所データサイエンティストはいま何を解いているか ── AIが変えた問題設定、変えなかった仕事」に参加してきました。この「LLM Wiki」の話が個人的にいちばん刺さったので、講演の内容と、Q&Aで聞けた話をまとめます。
自分はQAエンジニア2年からの開発エンジニア半年という若手なので、松尾研究所のような研究開発の現場がどうプロジェクトを回しているのか、素直に驚きの連続でした。
本記事は筆者のメモをもとにした参加レポです。数字や表現は登壇者の方の発表を筆者が解釈したもので、細部が違っていたらすみません（気づいた方はコメントで教えてください）。
勉強会の概要
松尾研究所のデータサイエンティスト3名が、それぞれの案件・働き方を話すハイブリッド開催のイベントでした。
- コーディングエージェント活用プロジェクト
- 購買データを用いたユーザーモデリング
- 松尾研データサイエンティストの働き方
この記事では、主に1つ目の講演（コーディングエージェント活用）と、会社紹介パートで聞けたプロジェクトの進め方、Q&Aの内容を扱います。
プロジェクトの進め方がまるごと「研究」だった
まず印象的だったのが、共同研究プロジェクトの進め方です。ざっくりこんな流れで進むそうです。
- 論文調査と従来手法の環境構築（最初の1ヶ月くらい。その間にクライアント側はデータ準備やユースケース検討）
- 手法の改善・新手法の検討（2ヶ月目〜）
- モック・デモを作って実際に使ってもらう
- 報告
成果物も「業務に導入して終わり」ではなく、論文化・学会発表まで狙うとのこと。さらに月1回のペースで松尾先生に進捗を報告し、毎週テキストでも状況を報告してコメントをもらうそうです。
会社のプロジェクトなのに、進め方がまるごと研究室のそれで、「産学連携ってこういうことか」と納得しました。論文執筆やアカデミックな出口まで含めてプロジェクトが設計されているのは、松尾研究所ならではだと思います。
本題: LLM Wiki ── 議事録も実験結果も全部mdで育てる
LLM Wikiとは
講演の中で「LLM Wikiって聞いたことありますか？」という問いかけがあり、これが本記事のメインディッシュです。
LLM Wikiは、Andrej Karpathy氏が2026年4月に公開したパターンで、LLMがMarkdownで書かれたナレッジベースを自律的にメンテナンスするという考え方です（原典のGist）。質問されるたびに元データから情報を組み立て直すのではなく、データを取り込んだ時点でWikiとして整理しておく、というのがポイントです。
松尾研究所での回し方
登壇者の方いわく、松尾研究所では半分以上のプロジェクトにLLM Wikiが導入されているそうです。仕様書のようないわゆる「ドキュメント」だけでなく、実験結果もプロジェクト推進の内容も、すべてMarkdown形式で管理して、エージェントと一緒に整理していくとのこと。
運用のイメージはこんな感じです。
- docsに仕様や調査結果がまとまっている（これがバージョン1）
- チームミーティングをすると、文字起こしがワッと出てくる
- それをWikiに取り込むと、新しい仮説・やるべきタスク・調査結果との矛盾が整理される
- それを踏まえて各人が調査や行動をする
- その結果がまたWikiに入り、Wikiが育っていく
人間もエージェントもプロジェクトメンバー全員でWikiを共有して育てる。次のセッションでは「現時点で考えられていること」を踏まえた議論から始められる。
「引き継げる」が一番刺さった
自分に一番刺さったのは、新しくジョインしたメンバーでも、ナレッジが溜まった状態から仕事を始められるという点です。
プロジェクトの文脈って、普通は人の頭の中とSlackの奥底に散らばっていて、新メンバーはそれを数週間かけて拾い集めるものだと思っていました。それがmdの束として整理されていて、しかもエージェントが保守してくれるなら、「引き継ぎ」の概念が変わります。
自分もClaude Codeに毎朝の予定とSlackの宿題を1通で提出させるルーティンを回していて、議事録やメモをMarkdownで溜め始めたところだったので、「溜める」の先に「エージェントと一緒に整理して育てる」があるのか、と視界が開けた感覚がありました。まずは自分のプロジェクトメモで小さく真似してみます。
「プロンプト以外に文章を書くことがなくなった」
コーディングエージェント活用の講演では、働き方のビフォーアフターも紹介されました。
以前は2週間1スプリントで、月曜にクライアントミーティング（スプリントレビュー）→ストーリーの洗い出しとスプリントプランニング→5日ほど実装→資料作成・デモ準備、という流れ。今は実装だけでなく、**スプリントプランニング・調査・報告資料の作成・データ分析まで、すべてにClaude CodeやCodexが入っていて、「単純に（生産性が）倍になった」**そうです。
数字も強烈でした。3〜4ヶ月前の発表時点でエージェントの呼び出し回数が30倍になっていたのが、今回さらに4倍。トークン量にすると月あたり約100億トークン（ご本人いわく概算）とのこと。コーディングをメインにしているわけではないのに、この量です。
Q&Aでは、この変化を一言でこう表現されていました。
プロンプト以外に文章を書くことがなくなった、のが大きな違いだと思います。そのおかげで自分の時間のレバレッジが効く、というような感覚を得ています。
「プロンプト以外に文章を書かない」は、資料もコードも調査メモも全部エージェント経由で作っているということで、さっきのLLM Wikiの話ともつながります。書く時間を減らすのではなく、書く行為そのものをプロンプトに寄せる。この割り切りは真似したいです。
Q&Aで聞けた話
Q&Aも学びが多かったので、印象に残った回答を紹介します（いずれも登壇者の方の回答を筆者が要約したものです）。
研究開発案件を顧客のビジネスにつなげるコツ
研究開発要素の強いプロジェクトが顧客のビジネスにどう貢献しうるか、うまくいった場合とうまくいかなかった場合の両方を、自分も質問してみました。
- うまくいったケース: 最初に論文のストーリーを検討する段階で、顧客の想定するビジネスユースケースをヒアリングし、それと整合するように論文の方向性を決めたのがポイントだった
- うまくいかなかったケース: 顧客担当者が興味を持った方向性の深掘りをメインに進めたものの、それが顧客ビジネスにどうつながるかを明確化できておらず、突っ込まれてしまった。最初にビジネスと学術的意義のすり合わせができていなかったのが反省点
アカデミックな成果とビジネス貢献を両立させる秘訣が「最初のストーリー設計」にあるというのは、研究開発でなくても通じる話だと思いました。
リスクで分けてハーネス化する
エージェントへの任せ方については、こんな整理をされていました。
最終報告などの大きな意思決定場面に用いるもの ←→ 少しズレていても問題ないもの、とリスクを分けてアプローチしています。高リスクほど人間の介入が大きいです。低リスクのものはどんどんハーネス化しています。ただこれはLLM関係なく、ずっと昔から基本とされてきたアプローチだと思っています！
「LLMだから特別」ではなく、昔からのリスク管理の基本をそのまま当てはめている、という視点が誠実だなと感じました。
コーディングエージェントが不得意な領域はどこか
これからのエンジニアの価値についての回答も印象的でした。
コーディングエージェントが不得意な部分を見つけ、その領域に素早くアジャストしていく力が本質的（価値になる）と思っています。そして、おそらくコーディングエージェントが得意になりにくい領域は、**強化学習しづらい（フィードバックループが長い・評価しづらい・デジタルに閉じない）**という特徴があるのではないかと思います。
「エージェントが不得意な領域」を感覚ではなく「強化学習のしやすさ」で説明していたのが目からウロコでした。フィードバックループが長い仕事、評価しづらい仕事、デジタルに閉じない仕事。自分のキャリアを考えるうえでも使える物差しだと思います。
Skill化の基準と、若手育成の話
エージェントのSkill（作業手順のパッケージ化）については、こんな基準を話されていました。
- Skillにするべき: 自分にそのスキルがあり、その作業が陳腐な（誰がやっても同じ）価値になっているもの
- Skillにしないべき: まだ自分にそのスキルがないもの
自分がまだできないことをSkill化すると、良し悪しの判断ができないまま自動化してしまう、ということだと理解しました。
そのうえで若手育成については、「育てる仕組みとコミットメントがあるなら企業として育てるべき。それがないなら、残念ながら若手なしで進めていくことになってしまうのではないか」という率直な見立ても。若手の身としてはヒリヒリする話ですが、だからこそ「エージェントが不得意な領域に速くアジャストする」を意識していきたいです。
まとめ
- 松尾研究所の共同研究は、論文調査→環境構築→手法改善→モック→報告という研究そのものの進め方で、論文化・学会発表まで狙う
- LLM Wiki（Karpathy発のパターン）が半分以上のプロジェクトに導入されていて、議事録も実験結果も仮説もmdで管理し、エージェントと一緒に育てる。新メンバーがナレッジの溜まった状態から始められるのが強い
- 働き方は「プロンプト以外に文章を書くことがなくなった」レベルまで変わっていて、リスクで分けたハーネス化、強化学習しづらい領域へのアジャストなど、任せ方の考え方も整理されていた
まずは自分のプロジェクトメモをLLM Wiki的に育てるところから真似してみます。やってみたらまた記事にします。