AIも不確実だけど、人間はもっと不確実だ

Claude Code is All You Need

https://x.com/trq212/status/1944877527044120655

Anthropicへ新たにジョインした方が、「周りの従業員がコーディング以外の分野でも幅広く Claude Code (cc) を活用しているのを見て驚いた」と投稿しているのを先日目にしました。具体的な話は上記のスレッドを見てもらえればと思いますが、journal、todo、ideasなどさまざまな情報をMarkdownでローカルに保存した上で、彼は $HOME でccを実行して、これらのファイルを参照させたり編集させたりしながら多くの作業を行っているのだそうです。

ccはCoding Agentではありますが、背後にいるのは汎用的な生成AIであることを考えると、めちゃくちゃ突飛なことを言っているわけではないと思いますし、昨今似たことをされている方は国内でもよく見かけます。Web UIでAIとチャットするのに比べると、テキストファイルでInputを取り回しやすいのが、ccを使う場合の大きなメリットかと思います。

最近、私も似たようなことをしています。journalやtodoといった、仕事のメモや記録をAIに読んでもらい、特にソフトスキルの分野でサポートしてもらうことにより、良い相乗効果が生まれていると感じています。

生成AIに何を任せると嬉しいのか

コーディング以外、と言っても具体的に何を任せられたら嬉しいのでしょうか。私の場合は、「人間が常に均質なoutputを出すのが難しい、不確実性の高い仕事」だと考えています。

最近、Martin Fowlerが Some thoughts on LLMs and Software Development のなかで、LLMによって、ソフトウェアエンジニアリングは決定論的な世界から、非決定論的な世界へ足を踏み入れた、と表現していました。従来のソフトウェアエンジニアリングは、同じinputに対してoutputの再現性が保証されるような、アルゴリズムを相手にすることが主だったわけですが、LLMはそうではなく、同じinputでも異なるoutputを見せてくる可能性があります。

逆に言えば、再現性は必要としないが、アルゴリズムでの表現が困難なタスクは生成AIに任せる甲斐があると言えます。例えば以下のようなことを任せています。

• 完了したTODOなどから、MBOやOKRの進捗評価に必要そうな材料を集めてもらう
• 最近の仕事やメモを読んでもらった上で、深掘りや検討が必要そうなポイントをピックアップしてもらう
• 1on1やMTGで話すべき話題のたたきを作ってもらう

いずれも最終的なoutputは私が思考して作る必要がある作業で、AIに任せているのはそのたたきやきっかけを作る部分です。このレイヤーであれば、outputに多少のブレがあっても許容できます。

私はミドルマネージャーの立ち位置にいることもあり、決まった解がない、問題そのものを発見したり定義したり、意思決定したりする仕事が多々あります。そういった、いわゆるソフトスキル面の仕事は、人間がこなしてもやはり非決定的になります。コンディションやバイアスに左右されがちな分、むしろ人間のほうがAIより非決定性が強いかもしれません。

不確実で解がない仕事のサポートに、AIは非常に打って付けだと思います。事なかれ主義で過ぎていきそうな日々に、AIに楔を打ってもらうような、波紋をもたらしてもらうような感覚です。

Logseqを中心としたInputの整備

上記のようなタスクをAIに任せるには、日頃の自身やメンバーの業務記録などをInputとして揃える必要があります。冒頭に挙げたAnthropic社員の例では、これを $HOME 下全体のファイル群という、非常に大胆な形で整えているわけですが、個人的にそれはちょっと怖い ^[1] ので、もう少し限定的なアプローチを採っています。

私はccが流行り始める前から、 Logseq というツールを用いて、ローカルでjournalやtodoを管理していました。最近ブームとなっている Obsidian に似た、 .md ファイルを用いたLocal Firstなノートアプリなのですが、名前の通りLog (journal)を重視する設計になっているなど、細部の使い勝手は異なります。

Logseqで書いたファイルはGit Repositoryの形で管理しており、このレポジトリ内でccを実行しています。具体的には、以下のようなファイル構造になっています。

.
├── .ai
│   ├── knowledge
│   │   ├── logseq-markdown.md
│   │   ├── personal-context.md
│   │   ├── team-context.md
│   │   └── weekly-journal.md
│   └── prompts
│       ├── 1on1-mine.md
│       ├── okr-progress-report.md
│       └── weekly-journal.md
├── journals
│   ├── 2024_04_18.md
│   ├── 2024_07_11.md
│   ...
├── pages
│   ├── All ToDos.md
│   ├── MBO___MBO 2025.md
│   ├── OKR___SRE 2025.md
│   ├── OKR___セキュリティチーム 2025.md
│   ├── pjt___✅なんかすごいPJ.md
│   ├── pjt___✅とても大変だったPJ.md
│   ├── pjt___頑張ってるPJ.md
│   ├── weekly___2025-05-12週のreport.md
│   ├── weekly___2025-05-19週のreport.md
...

Logseqではjournalのほかに、日付単位ではないノートも当然ながら作成することができ、それらは /pages 配下に保存されます。私の場合はここにMBOやOKRなどを記録することで、ccがこれらの情報を読みやすくしています。 pjt__ で始まるのは、チームのカンバンであるGitHub Issuesには載らないような個人の仕事です（例えば次年度の予算策定、来月のMTG用資料作成など）。✅が付いているのは、完了した仕事のファイルを視覚的にわかりやすくするためです。

また、仕事に必要な情報はローカル以外で管理している場合もありますので、NotionのMCPを繋いだり、 gh の実行を許可したりもしています。

余談にはなりますが、NotionのMCPはoutput手段としても使っています。思っていた以上に器用なことを任せることができ、「GitHubやLogseqからOKR進捗に関する直近の仕事の状況をまとめて、NotionのMTG議事録にあるテーブルの該当箇所へ書き込んでほしい」といった指示にも、柔軟に対応できたりします。定期的なMTGの資料作成は、ある程度定型的な仕事ですし、たたきを作る部分はAIに原則任せる形にできないかと考えています。

「テーブルから自分の書き込むべき欄を探して書き込んで」と指示した結果

Claude CodeとRooを使い分けながら思考をトリガーしてもらう

仕事の状況をinputとして揃えたら、あとはAIに適宜読ませて仕事をさせます。例えば毎週の個人的な振り返りサポートとして、以下のようなプロンプトを使っています。なお前提として、私がSREチームのミドルマネージャーである、といった背景情報は別途inputしています。

1. 今日の日付を`date '+%Y-%m-%d'`コマンドで確認します。
2. 今日から7日前まで1週間分の日報を @logseq 内から探して読んで、仕事の状況をトピックごとに要約してください。
3. @pages 内にある今年の現在のMBOとOKRを確認し、それに沿った業務が今週実施されていたか確認してください。
   - **重要**: 進捗している項目だけでなく、進捗が遅れている・具体化されていない項目も明確に特定してください。
4. ここまでの確認から、「危機の気配」「Next Actionが不明瞭な部分」「OKRやMBOの進捗が滞っていそうな部分」を抽出してください。
5. 抽出したポイントを1つずつ、状況や理由を私（マネージャー）に質問して掘り下げてください。
   それに対して私が質問に答えたり、追加で考察を述べます。必要に応じて追加質問やさらなる深掘りを行ってください。
6. 対話を通じて得られた気づきや考察を反映し、最終的な週次レポートを作成してください。

日報を使って振り返ること自体はひとりでも可能ではありますが、AIを使うことで、自分では見逃していた部分のピックアップなどのランダムネスが期待できます。感覚としてはセルフコーチングを助けてもらっている状態に近いです。

プロンプトは /.ai/prompts 配下にMarkdownファイルで配置し、AIに読ませています。ccであればslash commandにしても良さそうなところですが、これはccと Roo Code を現状使い分けているため、双方から読むことを考慮して、ツール特有の機能やファイルパスは使わないことにしています。

ccとRooをどのように使い分けているのか？ですが、自身の「気力」によってです。というのも、ccとRooで少し出力が変わってくるからです。

Rooは質問があるとき、回答の選択肢を用意してくれる

深掘りは対話形式で行わせていますが、ccがオープンクエスチョンで「どう考えています？」と訊いてくるのに対して、Rooでは問いに対する回答候補が表示され、クリックするだけで対話を進めて行けるのです。これであれば気力が足りない日でも、ある程度半自動的に思考が進められます。これを内省や検討と言えるのかというと怪しいところはありますが、何もできない状態になってしまうよりはマシです。

あと、Rooの一人称が「Roo」なのがかなり好きです。

Inputをどこまで揃えられるか、あるいは揃えるのか

ここまで書いてきているように、「思考のきっかけをつくる」ような使い方であれば、outputの精度は必ずしも高くなくても良いわけですが、とはいえ全くコンテキストを無視したoutputを出されても効果がありません。

一方で、Inputの精度を高めるにはより精緻かつ多量の情報が必要にもなり、それはそれで労苦がかかります。このあたりのバランスは常に探る必要があるところです。

Journalは自身の言葉で書いておく

ひとつ心がけていることとしては、LogseqのJournalは自動化せずに自身の言葉で書くようにしています。MTGであれば、結論やNext Actionに加えて、そのMTGの雰囲気や出席者の反応、自身の主観で感じたことなど、暗黙知になる部分を意識的に書きます。個人のJournalを持っておく利点はここだと思っています。

なお、Claudeは入力データの学習利用をオプトアウトしてはいますが、念の為個人名は偽名やイニシャルで書いています。

AI自身にコンテキスト情報を育ててもらう

Journalは自分用に書くものなので、主には自分がわかる記述になっていればよく、背景情報も含めて丁寧に書くことは稀です。しかし、これではAIにはハイコンテキストになり、outputの精度が落ちる場合があります。そのような場合には都度チャットしながら情報を提供し、AI自身に /.ai/knowledge/ 内へメモしてもらっています。

AIと対話しながら、仕事のコンテキストを積み上げていく

当然ながらAI導入前にもJournalの振り返りは行っていたものの、多量のJournalを一つずつ読み返すのはマンネリ化してしまう作業ではあり、読み飛ばすこともしばしばでした。やはり人間のほうがAIよりさらに不確実ではあり、AIのほうがきちんと1週間をサマライズしたり、然るべき話題をピックしてくれる感があります。すると、「書いてさえおけばAIが拾ってくれる」という意識にもなり、Journalへの向き合い方も変わってきました。Journalを素材としてAIと対話するなかで、Journalの書き方をブラッシュアップし、結果的により良いOutputに繋がる循環を上手く作っていきたいところです。

もちろんJournalを上手く書き残せなかった日もあったりはします。数時間MTGが続くと、なかなか自分のためのJournalを書く暇が取れないこともしばしばです。そもそもMTGを減らせ、という話もありますが、例えばAIと対話しながらJournalを書くなど、ここも何かしらAIを活用する余地があるのかもしれません。

脚注

1. ~/.config なども読める状態は何か事故りそうな気がしてしまいます