もっとAI使おうぜ！！！

2026/08/24の社内LTでしゃべったやつの公開用に整えたやつ

Transcript

1. もっとAI使おうぜ！！！ おかき（koinunopochi） 1
2. ※予防線 • • • • めっちゃポジショントークです。 話半分ぐらいで聞いてください。 最近はうまく使うと全然トークンが減らない、$200使い切らないみたい な話も聞こえ始めたので周回遅れの話なのかもしれずちょっと怖い。 結局抱えているタスク次第なところはある、自分はヒラの開発者なので、 AIとの相性は良いかもしれない。 2
3. 余談：久しぶりに自信作 筆？が乗りすぎた（100枚超えちゃった）ので、あとで読んでねでめっちゃ飛ばします 3
4. みなさんAI使ってますか？？？ 4
5. もちろん使ってますよね？？？ 5
6. 使いこなしているって 6
7. 胸を張って言えますか？？？ 7
8. 自信がある人は少ないはず 8
9. 自分も正直、 微妙 9
10. でも、 10
11. AIをしばき倒している 自信はある 11
12. 今のAIの構成 • • Claude $200 Codex $20 それなりのアウトプットは出していると思うが、 効率は多分よくないと思う 12
13. 大前提 たくさん使っている≠えらい 13
14. まだもうちょっと前フリが続きます 14
15. トークン効率？ 15
16. AIのトークン効率の話題を見かける 16
17. https://engineering.dena.com/blog/2 026/08/ai-token-cost-report/ APIコストなのでサブスクとは若干違う が、どのプランを使うかには通じているは ず 17
18. https://blogs.itmedia.co.jp/osonoi/20 26/06/aifinops_x_2026.html 18
19. https://ai-revolution.co.jp/media/ent erprise-ai-cost-challenges-2026/ 19
20. 事実 営利企業である以上コストの話は大事 20
21. とはいえ、こうも思います 21
22. AI遊び尽くしていますか？ 22
23. リミット気にしてセーブしていませんか？ 23
24. やっと本題です 24
25. 量を増やしましょう。 25
26. 概念 量質転化の法則 ドイツの哲学者ヘーゲルが提唱した概念で、ある量が一定の限界を超えると質的な変化が生じるというもの 26
27. 「量のない質はない」 という考え方がある 27
28. $200を使い潰す勢いで使って 初めて見えてくる景色がある ...はず 28
29. 再掲 事実 営利企業である以上コストの話は大事 問題提起？ $200ドルのプランを 使い切ってから 考えるべきではないか 29
30. 再掲 事実 営利企業である以上コストの話は大事 問題提起？ $200ドルのプランを 使い切ってから 考えるべきではないか すでに使い切っている人は、Opusで質を 担保するには？Sonnetにするには？など 考えるタイミングだと思います。 あとで救いのある話にす るので、安心してくださ い。 30
31. たぶん $200プランを使い切るってむずかしい 31
32. これから$200ね！って言われても... 32
33. まずは、使い切ることを目的にしていい。 • • • • • • どれだけ使うと利用上限に達してしまうのかを把握する。 何をするとトークンが意図せずに使われすぎてしまうか把握できる。 AIを大量に使おうとした時のボトルネックが即座に可視化される。 Chatとして使う場合は使い切るところまでにパワーが必要、なので 無理 やり意識する必要がある。 $20, $100程度で、 コストを意識し始めるとAIでの自動化なんてできな い。 権限委譲・業務効率化 するならサブスクを最大限活かす必要がある。 90万円分使っても3万っすよ！！！！ 33
34. つまりな話。 34
35. 余談：GPT image 2の画像生成優秀っすね 35
36. 以外と簡単にできる気がする 余談？：5時間制限を4~5回＝100％ Fable・Opusだけを使ってれば簡単に リミットに引っかかりそう 36
37. 余談：Fableメインで使ったけど高え 37
38. $200を使いつぶせ そんなことを言われても困る 38
39. ...と思うので 39
40. やりかた！！！！ 40
41. これから出てくる痛みは、全部自分が体験したり思ったりしたことがあるもの インターネットの海にはもっといろいろあると思う。 本当に最前線を走っているわけではないので、最前線の使い方とか感覚とは違う可能性がある。 自分なりに噛み砕いてもらえれば嬉しい。 41
42. とにかく ”並列数” をあげるには？？ 42
43. 最初の頃に出てくるだろう痛み。 • • AIを複数動かすと、何が動いていて止まっているかわからない。 AIからの質問・許認可で処理が止まってしまう。 並列数をあげるには、自走力をあげるにはまず超えるべき壁 43
44. herdr/cmux の波に乗ろう。流行っている理由があ る。 https://herdr.dev/ https://cmux.com/ja 44
45. ここがいいよ！！herdr / cumx ！！ • • • • • • • • codex claude が簡単な設定で通知できる tmux とかで設定すると面倒なマウスでの操作とか最初から入っている UIがなんかカッコよくてテンションが上がる。 👈だいじ ターミナル感が薄れるので、bizでも触りやすくなる 作業中か、処理が終わっているのが画面を見ればすぐにわかる tmuxとかでできることはだいたいできる。 （細かすぎるところはできないこともあるはある） （エンジニアが使ってるので、vscode拡張とかよりも教えやすい） 45
46. これだけだと片手落ち 結局、許可するまでブロックされる 46
47. https://qiita.com/ha_naopapa/items/23c53262d8151e4d766e なんでも実行モードで実行する？？ • • • • • • 読まないで承認していないですか？ 読んでないなら実質変わらん やっちゃっていいんじゃない？ Autoモードがデフォルトになったので、それでもいいが、夜寝る前に長 時間のタスクを任せるなどができない。 対策はしつつやっちゃうのがいい気がする。（とっても無責任） 大事なデータはGoogleDriveに同期しておく。GitHubに上げてバック アップしておく。など、ローカルには何も置かない。 VMの中で動かす Hooksなどで危険な操作は塞いでおく （PCが吹き飛ぶなどのときに） 情シスに土下座する覚悟を持つ。 47
48. 最初の頃に出る痛み 2 • macがスリープすると処理が止まる 48
49. 設定で解決しよう • だいたいのことは世界ですでに誰かが踏み固めた道です。 つらいことはAIに聞いたり調べると意外と簡単に解決できま す。 ネットでいっぱい記事があるので設定してみよう、方法がある＝AIに聞 く。設定も手伝ってもらおう。 https://zenn.dev/persona/articles/5bd040bc9dd48b 49
50. 次に出てくる痛み。 • • • 毎回同じことをきかれる トンチンカンなことをする slackに、backlogに、zohoに、etc... あるのに情報のコピペをしない といけない 50
51. 専用のツールで人の手を減らそう。 • • 変なことをするときは、 1. 情報が間違っている 2. 情報がない のどちらかです。 mcp, cli, コネクタなど今はだいたいなんでもあります。 公式の使うとか、APIの薄いラッパーを自作するとか。 skillsはツールの使い方ではなく、 コンテキストを与える。 CLIでもMCPでも--helpでAIは理解できる。 ドキュメントの場所だけ置いておけばOK 51
52. 次に出てくる痛み。 • • • AIからの情報量が多すぎて、判断が適当になる 動かせる作業量が増えすぎて判断に疲れてくる レビューなどAIの成果物の確認に時間がかかってしまう 52
53. 判断に不要な情報を減らす努力をしよう。 • • 目的外の情報、余計なバージョン情報などノイズが多すぎる。 自分なりの最高を作りましょう。 https://gist.github.com/k16shikano/fd287c3133457c4fd8f5601d 34aa817d 手順書等はHaikuと かアホなモデルで意 図通りに動くか検証 すると良い。 自作する 53
54. レビューしやすいツールを作る。使う。 Chatでは流れてしまうのを、ツールで解決する 良さそう（試せていない。） 54
55. これだけ”努力”したから大丈夫と思え るレベルで作る。受験と同じ話。過剰 でもいいから、このレビューを通した ということは質的に担保された証拠と 思う。 根本レビューしなくて良い仕組みを作る。 機械的に保証し、見るべき場所を減ら す。 • Linter • 静的解析 • レビューで指摘する構文的な問題 を検知するスクリプトなど 過剰なレベルでいいので、 レビュースキルを整備する • • • ワンショット$200分ぐらいかかっ てもいい。 時間が2時間かかってもいい。 それで安心できるならむしろ安 い。 チーム内で、AIレビューOK 動作チェックOKなら信頼するという 合意形成が大事。 55
56. 次に出てくる痛み。 • • • • （運用が長くなると）環境が汚れてくる。 ドキュメントなどが増えすぎて精度が下がってくる。 Docker環境が乱立、一時的なファイルが汚染。 古くなってしまったドキュメントなど。 56
57. AGENTS.mdに禁止を書かない方法を検討しよう git hooksなどで禁止する・促す 保存する時、何かを作る・更新するときに大丈 夫？と入れるだけでもだいぶマシ AI Slop的な単語がないか？ ドキュメントは読みやすいか？ 余計な場所にcloneしていないか？ フォーマットは正しいか？ 指定したツールだけを使っているか？ スクリプトで検査できる形 でドキュメ ント自体を構成する 57
58. $200プランを瞬殺するエッセンス • 並列で運用する。（それができる体制を整えるためには？） ◦ ◦ • AIに任せても安心な範囲を広げる（そのためには？） ◦ ◦ • リポジトリにブランチプロテクション、マージブロックなどを入れる。 githooksなどで守る。 人間を挟まない。 👈結局一番は人が遅い原因。 ◦ ◦ • 簡単にDockerのポート競合を解決できる仕組みの作成 AIと複数並列で会話しても疲れないようにする、自分なりのツールの作成 最初に方針を定め可能な限り自走させる。 質問は最後にまとめさせる。 エージェントを大量に利用する 👈金で精度を担保しましょう。 ◦ mainのコンテキストを汚染しない、grepを使うと精度が悪化するため。 “精読”させる。sonnetなど安いモデルに1~5ファイルだけ読ませるなど。親は高いモデ ル 58
59. 人間の認知、協調性は有限 • • • • ちょっと発散してしまっている が、話したい 可能な限り人間の認知負荷、判断コストを下げる必要がある とにかく並列数をあげるには人間側がボトルネック 動作チェック、仕様の把握、リリース日の調整、そういったところが次は ネックになってくる チームで動く以上、仲間にコストを押し付けない動きをしていく必要があ る 速度は上がるがその分ゆがみが出てくる。 新しいことを始める以上それは絶対。 人として信頼される、この人なら安心。笑って土下座できる関係の構築。 結局関係性に左右される。 コストはAIに押し付ける。それをしていかないと回らなくなる。きっとお互いの仕事もしづらくなる。 59
60. 脇道にそれましたが改めて 60
61. $200が営業日分持たなくなって 初めてコスト戦略が必要になる もちろん安いプランでもある程度コストは見るべきだが、圧倒的に使い続けない と削減できるポイントなんてわからない... 61
62. 自分の場合。 • 主に利用しているモデルは sonnt5 のmidumと gpt 5.6 luna max ◦ • 原因1：レビュースキルの精度はいいが、コストが高すぎる ◦ ◦ ◦ • 初期ワンショット$200分ほどのトークン利用、2時間程度（一部Opus, Sonnet） 少し前、$100、1時間半程度（Sonnet, 一部haiku） （改善作業中now。そもそも構成が悪い。無駄が多い。遅い。） 原因2：ナレッジのリポジトリが破綻（していたっぽい） ◦ ◦ • • それでも トークンが持たない。 直近で一気に精度が悪くなり、修正中。（もっと前からトークンは比較的カツカツ） 修正のために余計なトークンが発生、指示に従わないためhooksなどを調整した結果コン テキストのゴミによりさらに悪化など。 原因？：いろいろな場所の改善などに手を出している分、並列数が多い 原因？：求める質が高いのと茶々入れがめっちゃ多い ◦ それこそskillsやコンテキスト注入不足なので、使いこなせていない場所 62
63. 手軽に始めるには？おすすめな方法 • claudeの場合。 ◦ ◦ • claudeのweeklyのトークンの20％ほどは環境の整備などに使う。初期では100％でも い プラン昇格の基準。 ▪ いつもより少し立て込んだ結果、1日でweeklyの40~50%使ってしまう ▪ 月曜始まりで、水曜日の午後には80%程度になっている状態 codex で $20を契約して、gpt-5.6 luna max を利用する。 ◦ ◦ ◦ ◦ 良 👈おすすめ 感覚的にはOpusレベルの知能が、haikuのコストで手に入る。 luna maxだけの利用で、50%ほど利用できれば、 claudeの$200を使い潰せるだけのパワー を手に入れることができているはず （Fable5使わないなら codex の方がいいと思います。） ※ solとかteraとか使うと$20は一瞬で溶けます、正直使う必要はないぐらいにluna が 優秀 63
64. 再掲 再掲 事実 営利企業である以上コストの話は大事 問題提起？ $200ドルのプランを 使い切ってから 考えるべきではないか まとめ 現状質を担保するための量が足りていない。 codexの$20から量を担保すると良いのでは？ 64
65. 本気でしばき倒してみませんか？ 65
66. めざせ！AIちょっとできる！ 66
67. codexはいいぞ！！！ 67
68. 余談：交流しましょう 大声で仕事をしよう timesはいいぞ！！ ほかにも#times-◦◦ で調べればいっぱい あります https://qiita.com/kurifumi/items/417857232f85d3b79c56 AIの情報とかtimesにtwitterの転記してたりするので、流し見す るだけでもAI情報は追いやすいはず 68
69. こっからの余談は全てスキップ 69
70. 多分いいこと書いた 70
71. 余談からが本番 71
72. $200を1年しばき続けて見えた世界 72
73. 読むのめんどいよーとかであれば 喋るので投げてもらえればと 73
74. 余談：シンプルが一番難しい シンプルで最大限効果を発揮するスキルが話題だが、 自分の技術力ではFatに作って余計な部分をこそぎ落としながら進めていくの が良いのではとか思ったり。最初は効率が悪くても金で殴ろう。 • • grill me eli5 一行とかで、すごい効果あるのでオヌヌメ 74
75. 余談：claude標準のmemoryは利用しない 削除漏れあったので、この後 削除とhooksでさわれないよ うにした 👇 何が悪い？ 意図した目的を持った記録ではなく場当たり 的な記録になりがち。目的がはっきりしない 資料は使い道が生まれないゴミとなる。実際 claudeがこれをまともに活用できるのは本当 に初期だけ。これ使うぐらいなら、自分で 使った方がマシ？？今は違うかも、、、 75
76. 余談：環境が荒れてきたシグナルに敏感になろう。 /contextコマンドなどで見た ときに、起動した瞬間からコン テキストがたっぷり状態 トークン消費が早い 他の人の悲鳴が聞こえる前に精度が悪化す る むしろ邪魔な情報 が多すぎた ディレクトリ構造からくる見通しの悪さ 76
77. 余談：ディレクトリ構造の見通しの悪さ • • • • • シンボリックリンクとかで配線するから適当でいいやは通用しなくなる AIは自分よりも確実に優秀ではあるが、それを活かすにはそれなりの環境 があってこそ。 人間が初めてのでけえモールやスーパーに行ったときに導線が悪くて迷う ように、明示的でわかりやすい設定。絶対パス、相対パスによる確実な導 線の保証。 そもそもの見通しを確保して、0情報からでもスッと走れるだけの道を整 理する。 コーディングと同じで、単一の目的、責任、明確な意味、ヘタな依存を作 らない。依存の分離、境界づけられたコンテキストの整理。が大事 77
78. 余談：スクリプトで検証できる範囲を広げる • • • • • AIの処理を信頼しない 頭は確かにいい。でも使う側が間違ってしまう時がある 複数並列をすると、ひとつにそこまで意識を避けない だいたいどこかでわけわからなくなる 失敗しても、指示を間違っても、曖昧でも、軌道修正できる体制を整えま しょう 78
79. 余談：環境が荒れてきたなーとなったら • • • • • • 今の環境を捨てましょう 無理やり生かしてきましたが、根本的に破綻するタイミングがきます なぜ、この環境が必要なのか、目的は？、結局何が必要なんだっけ、それ さえ整理できれば95%ぐらいのファイルは捨てて、まとめることが可能で す。（体験談） AIがそれこそ優秀なので式年遷宮のがいいっす チームでやろうとしている環境もいろいろしくみは入れているものの、 持って3ヶ月かも？？？ AIしばき隊の人数が増えればそれだけ加速度的に環境は汚れるw 79
80. 余談：スキルにはツールの使い方を書かない。 • • • • • • ツールの説明なんていらない。 –helpや、ドキュメントのリンクを一行貼ればいい。 なんのためのツールかも1行ぐらいであるとよい。 あとは全部IDとか、名前とか、そういった人間なら知ってるけど、AIが知 らないと困ってしまうやつを載せる。 名前とIDの紐付けとかね。そういったやつです。 ネットで調べても出てこない情報は載せるべき。公式に提供されていて ネットにあるなら載せない。そのぐらいの切り分けでいい。 80
81. 余談：codexはmcpとかの設定とかクセがある • • • claudeとかもアカウントごとにmcpの設定とか紐づくので、移行ビリ ティ、乗り換えビリティ、並列ビリティは考えていきたい。 おすすめは全部CLI自作しちゃう。 MCPとかもタダのサーバーなのでOSSで公開されてたらなんとでもなる。 まだ自分の中でベータみたいな感じなので、サクッ と使っていいよ！とは言いづらい 81
82. 余談：チームでMCPの運用したくない • • • • • チームでMCPの設定とかはしたくない。 理由としては、グローバル設定などに引っ張られたり、ローカル依存が強 すぎるため、設定しづれえので、問題の把握とかむずいとかあるため チームで運用ならCLIがいいと思う コンテキスト管理的にも、無駄にスキル書いてあったりして制御しづらい ので普通に今の時代は自作が正義。 公式に提供されているskillsやプラグインはエッジケースまで網羅してて コンテキスト圧迫がひどい時がある。情報は自分で管理した方がお得...な こともある 82
83. 余談：チームでAI運用するなら、環境の統一が一番楽。 • • • • • ナレッジリポみたいな外部リポジトリを用意して、横断的に扱えるスキル やコンテキストを持つ仕組みを作る。 可能であればディレクトリ構造も強制的に同じかたちをとる。 破壊も、退行も進化もチーム内で即座に享受するために。漢のmain1本勝 負がいい。ブランチを分ける運用をすると、差分が発生しすぎてチームで 運用する価値がなくなる。（個人でもなりかけたのでチームでは不可能） ナレッジやスキルの更新頻度とサービスの更新頻度は一致しない。常に最 新であるべき情報は鮮度が命なので、時間軸が違う以上保存する場所も分 離すべき。 基本的なドキュメントに関しても今後は分離していった方が良さそう。 83
84. 余談：速度感を出すために • • • • • • チームでAIを使って速度感を出すためには許容すべき痛みがある。 コンフリクトや退行など。 検証用のブランチなどを用意すると速度感が落ちるのと、結局他の人の変 更とコードのようにマージブロックできるわけでもないので積む。 目的が混ざったスキルは良くないので、混ざるぐらいなら上書きする。 感覚的にぶっ壊れたと思ったらわかるので、自信があるタイミングでタグ を打っておく。 Git管理さえしていればなにしてもいい。を合言葉に。 84
85. 余談：人のスキル使わない問題 • • • • • • 思考の形が合わないので、使いこなせないことが多い。 意識させない設計が大事。 作り込まれたスキルは、自然に発火するし、使いやすい。 これは目的がはっきりしていて、発火しやすいのもあるし、人間もAIもわ かりやすいため。 メンタルモデルが違うと言葉の出し方、依頼の仕方が違う。実は数日間と なりで一緒に作成者と作業するとかいう古典的な方法が最も効果が高そ う。 これからチームで運用していく中で確認かなと。（まだできていない） 85
86. 余談：使い方がわからないなら説明させればいい • • • • • • スキルとかナレッジ系のディレクトリは、ある程度思考のクセとかが出て くる場所。 メンタルモデルの構築が大事。 そもそもの設計思想とかを理解すると、なんとなく使えるような感じに なってくる。 これできるなら、あれいけそうじゃね？みたいな。ファイルの想像とかそ ういったのが構築されていくはず。 それをAI使って、こんな感じの背景と目的で作られていますなどの共有を 最初にやッちゃうのが良さそう。 それでもダメなら先程の通り、となりで一緒に作業が一番良い。 86
87. 余談：人間の認知負荷を下げる • • • • • • • • skillsやmcpが乱立すると正直把握しきれない。 自作cliを推すのは、見るべき場所を自分で制御できるため。 また、skillsなどに関してはエントリーポイントを3つ程度に絞るべき。 自分は開発者なので、dev, review, 日本語スキルぐらい。 調査とか基本的に必要なスキルは全て、devの中のrouterが呼び出すイ メージ。仕事は全部開発に関連するという開き直りも大事。 UI設計と同じで、見せる必要のない情報は露出させない。 破綻したら、抽象度をあげる形をとりましょう。破綻するまでは忘れるの が吉。困ったらdevを修正して、ぐらいの形をとるのが一番良い。 ノイズを減らしましょう。認知力は有限です。 87
88. 余談：MCPが悪いのではなく既製品の時代ではないかも • • • • • MCPもCLIのその他ツールに関しても、エッジケースまで対応しようとし ます。 それはいろいろな人が利用するからです。 今の時代、私は何をしたいのか、どうあってほしいのかが重要。 他の人の使い方は重要ではあるが、100あるツールでも1つの機能しかな いのであれば、それに書かれているドキュメントなどは不要。 もちろん巨人の肩に乗るべきときが大部分。でもそこから薄いラッパーで AIの制御をつけたり、いくつかの不要なツールを見えなくするなど、細い 調整はしていくと体験がいい。 88
89. 余談：コンテキストはみんなが見れる場所に！ • • • • • • AIにもろもろ検索させるときは、基本的にslack起因になる。 一番コンテキストがあるので。 backlogやdocbaseとかにするにしても、どこかしらslackにリンクした い コンテキストを発見できないから、人間がサボるためにもドキュメントの タイトルと、リンクだけ貼る。オープンでできる会話はオープンでできる と大変良い。 AIだけじゃなくて人間もこれは助かるので。 AIも人間も結局依頼した人などの会話から探るはず、会議がありました。 資料貼るだけでもあとから見た人・AIは喜ぶはず。 89
90. 余談：資料の添付とかはtimesでいい • • • • • • • • • • • • 自分は、Botをつかって自分のtimesに飛ばしたりしている。 逆にtimesのをチームのところに飛ばしたりもする。 メモとかも公開できるものは全部そこに置く。 どうしても公開できないものは、DMなどに置く、スプシで権限切るなど みんなが見れる、検索できる背景、試行錯誤を知れる状態はAIビリティを著しく高める どこでもいいので雑に作業内容とかを共有できる場所を作るべき timesをおすすめするのは、意外とタスクっていろいろなところで発生するので、なんでもかん でも放り投げていい箱があったほうがいいなと思うため 別にtimesでなくても、ずっと進捗状況とか詰まってることとか考えていることを垂れ流せるパ ブリックな場所があれば良い。 チームの人にそこで作業していることが伝わるとなおよい。 横断的に作業していると、個別チャンネルとかプロジェクトでのやり取りは場所が増えたり、情 報が流れてしまうデメリットがあるので意外と気を使う。 気を使わなくていい状態、状況を自分から作っていくのが大事。 みんなに見られているという意識があると気も引き締まるので、仲良くしたい人とか情報を共有 したい人を入れるの大事。 90
91. timesはいいぞ！ 91
92. 余談：GlobalのCLAUDE.mdは使わない • • • • • • そんなに広範囲に当てるべき事象なんてそうそうない。 個別に日本語でとか書いてたりするので重複する。 日本語ですらconfigで指定できる。 git管理されていないので、事故すると面倒。 全ての設定はワークスペース的なリポジトリ内で完結し、外部の設定を利 用しない形を取ると、見通しがよくよい。 （AGENTS.mdも） 92
93. 余談：油断するために最初は妥協しないのが大事 • • • • • • 新しい仕組みを入れたら満足してしまうことが多いと思う。 ちょっと違和感あるけどいっかーみたいなの。 それを放置すると、あとで苦労します。絶賛している途中。 要はお前さんは何をしてるの？どこからその情報を引っ張ったの？その情 報を直す？アウトプットの質は？などとにかく違和感にしたがって潰して いく必要がある。 AIの並列度が上がってくると、判断の質は下がって然るべき。 基本的に意識1割を割けたら御の字のときに迷わない形を準備する。 93
94. 余談：全ての根幹は、日本語スキル • • • • • • • • 日本語がまともじゃないと読む気にならん 読む気にならんとなあなあに済ませがち なあなあにするとなあなあが増殖してつらくなる。 スキルや文章を書くときも、何にしても迷わない文章が現状一番大切。 人間が迷わずに読めるということはAIも同様になる。 あいつらは、自分で書いた文章に苦しめられるが、嬉々として書くので。 認知負荷を手っ取り早く下げるには自分の思考のリズムに合わせた文章構 成能力を作る必要がある。（≒日本語スキル） 日本語も確かに悪いが、構造とか文章の構成能力をいじったほうがいい。 94
95. 余談：はっきりとした目的もすっごいだいじ • • • • • • 目的は、残さないと残らない。 目的は、整理しないと残らない。 目的は、すぐに忘れられる。 目的は、すぐに膨らむ。ズレていく。当初の目的なんてどっか行く。 skillsでもディレクトリ構造でも目的は大事。なぜやったのか、なんで今 こうなっているのか、通常の開発でもなんでこれやったの？それを残すの がだいじ。 またアーキテクチャデザインと同じ。ディレクトリ、構造、命名、そう いった節々を妥協せず、構造から意図が推測できる形を取る。 👈維持は めっちゃ大変。 95
96. 余談：曖昧な意思決定を記録しない • • • • • • • • • Any DR をAIと一緒にやっていた。 ※ 全ての意思決定を記録しましょうってぐらいの概念。 本来はいつかのために、意思決定を残してあとで拾えるようにしたかっ た。 （多分最初から）記録することが目的になっていた。 ABCの案が勝手に作成され、Aが自動で採用される。 ただのゴミである。あくまで目的を持って意思決定などをやっていける形 を作る必要がある。 目的の棚卸しは大事。 これは作業ログ的なのを使うようにするのが良さそう。Any DRに求めて いたのは、試行錯誤の過程であって、記録ではない。 試行錯誤のログからあとで逆引きできればいい。 96
97. 余談：スキルなどを編集した場合は目的の整理をしよう • • • • • 既存の目的は古くなっていることが多いです。 少なくとも、あとから追加した分は、どこまで行っても既存の形式に引っ 張られます。 本当に欲しいものはなんなのか。今の構造は最適化されているか？それを 何回かやることで、スリムに質の高いドキュメントや資料が作成されま す。 1文字でも変えた場合は、正直再構成ぐらいの温度感高め。 あとからの追加は、絶対に新しい意図がある。 97
98. 余談：ドキュメントはすぐに腐る。 • • • • • • • • • AI時代5分で腐る。 ドキュメントは利用目的を持って作る。 だいたい腐るだろう期間を事前に指定しておく。 機械的にパスの判定とかで、ファイルが死んだらわかるようにする。 無駄なドキュメントは作らねえ。tmpに作っておいて破棄するが大事。 git管理しておいて削除して、困ったら復帰が楽。 コードと同じ。状態を持つとツライ。 状態を持つ、保存する質のドキュメントは可能な限り作らない。 逆に、今のコンテキストを表現する、制約のドキュメントなどは積極的に 作っていい。タイプによる。 98
99. 余談：サボる場所とダメな場所を見極めよう • • • • • • • 「とある王国で横領が発生した。緊急用の倉庫に備蓄されていたコメの数が足り ない、石でかさ増しされていた。王国の兵士は、帳簿上よりも限りなく少ない食 事により士気が下がりその戦いは負けてしまった。」 「宰相はいった。良い横領と悪い横領がある。一族の商人を使うなどは良い。帳 簿と実態が違うのは 👆の理由でダメ。」 昔読んだ小説でこういった話がある。 人間もAIもサボる場所を見極めるべき。 倉庫（備蓄米）は実データ。帳簿は、ドキュメントなど。 基盤のぐらついたドキュメントほど悪いものはない。腐ったら腐っていると気が つける状態を作る。 or 事実をドキュメントにはしない。ツールで静的に正しい ものを作るなど。 基盤を担保するためには、トークンも人間の認知も支払っていい。ここは妥協し てはいけない。 99
100. 余談：状態は揮発するが残ると一生の苦しみを生む • • • • • • • • その作業をどのように進めていたか、どうやっていたか なんのために進めていたか そういった状態は、セッションを閉じると簡単に揮発します。 作業の内容で何に苦しんだかなどは記録したいといった欲求が出てきま す。 しかしその苦しみは、あくまでもその時点の”状態”と合わせて初めて意味 を持ち、記録されてしまうことが多いです（日本語が悪い） ここが残り続けると、この作業が終わっていないです。こんな問題があり ますと、過去の資料を引っ張るが今は治っているみたいなことが多発しま す。 やはり、日本語、、、日本語スキルは全てを解決する！！！ （多分、構造化や抽象化、場面の選択とかのための背景推察能力系の思考 形態とかを用意する必要がある） 100
101. 余談：結局は地力がものを言う。 • • • • • ここ一年ぐらいAI触ってきたが、ナレッジの収集や、オーケストラレータ などいろいろなことを試した。 だいたい既存の、DDDやイベント駆動だったり、その他KISS、YAGINIな どの設計原則に帰ってくる。 本当はデータレイヤーの抽象化だとか、DB的なサムシングとかなんかもっ といい手はあるかもしれないが、ひとまず一般的に使われてきた、コー ディングにおけるルールはやはり間違っていないんだなと再確認。 そこら辺の知識を抽象化して適用していく力が今後は必要になっていきそ う。（それすらも、もうちょいしたらいらなくなるとは思う） 今はまだ大事。これも結局はコストをどこにもつか。人間が責任を持つ か、それとも精度で支払うか。 101
102. 余談：（今は）人間が容易に処理できる形を取るべき • おそらく将来的にもトークン効率など、経済性の話から変わらない気もす るが、人間の把握できる範囲、管理できる範囲でやるべき。 102
103. 余談：人間は意思が弱い。やらない。 • • • • • 人間は基本的に、期限のないそんなに重要ではないタスクはやらない。 棚卸などをAIに将来はやりましょうね！と言われてもやらない。 元から人間は見ないよ。を伝えておきましょう。 AIは人間を過剰に評価しています。そんなに意思を強くもつことができる 人間は少ないはず。 タスクに追われてできないこともあるし、そもそも忘れるとかめんどいと か。人間は信頼しない。 103
104. 余談：AIにムカつく • • • • • • • 誰が、今、なんの目的で、どのような背景を持って、この仕事を依頼して おり、いつまでに、どういった形で、受け取りたいと思っているのか。を 練りに練った形で資料や会話をする。 とかなんかそういったこといえばマシになる。 AI Slopな文章の大部分はコンテキスト不足と思考が浅く背景や意図の把 握ができていないこと。 誰が何を求めているかによって文章は変わってくる。 「効く」とかはだいたい機械的にモグラ叩きをしましょう。 一応、ものを比喩的に表現する動詞を使うなとかなんか指示すると多少は まともになる。 codexはもともと日本語キレイな気がする？多少アレではあるが、 claudeの方が透かしの影響か、汚い印象 104
105. 余談：AIだけではなく人間も信用しない。 • • • • • • • AIはもちろん頭がいい。基本的に情報が正しければなんでもできる。 だいたいのことは人間が悪い。 人間は適当なので、適当なアウトプットになる。 人間の信頼性は低いのでそれでも動く形を作る。 人間の信頼性が低いので、金で叩く。 トレードオフは、それこそトークンコスト。人間が真面目であるならトー クン効率は良くなる。 やはり、早急に解決しないといけない課題があるときに、今そこ気にしま す？って話になる。 105
106. 余談：頭のいいモデルが使いやすい理由 • • • • • • • • • • こっちの背景とかなにを目的にしているかを少ない状態から察してくれる力が強い。 これは、モデルのサイズに依存するっぽい。 でっかいモデルは察する力が高い分、高価。 安いモデルでも察するとは何かをブレイクダウンして、考えていけば多少マシになる。 ここは今のAIでも自己分析は甘いのでみんなで苦しんで頭を使いましょうって部分。 別に感覚でいい。なんとなくこうなると思って依頼したのに、こうなった。なんでか一 緒に壁打ちしよう。とか。最終的に構造的な問題とかに着地できるといい。 とにかく壁打ちをすると、AIのメンタルモデルや思考のクセがわかってくるので、依頼 しやすくなる。 人間でもAさんにはこうやって事実から〜などあるのと一緒。 お互いに気持ちよく一緒に仕事するならAIの思考の方法を理解してやる必要がある。 察して、はAIに負荷をかけている状態。ここの負荷は、人と違いコスト・アウトプット の質として表出する。 106
107. 余談：抽象と個別具体を反復横跳びさせよう • • • • • 人間と一緒。机上の空論はうまくいかない。 ユースケースを洗い出しブレイクダウンする。 数回繰り返せばそれなりにまともになる。 抽象、個別具体、反証、検証、実証、ここを回すと安定する。 結局愚直にやらせる。愚直にやるとなると金と時間がかかる。 107
108. 余談：思考を止めない • • • • AIの言っていることがわからなくなることがある。 なあなあでやってよかったことはない。 それこそプライドを捨てて、5歳児に向けて説明してもらいましょう。 思考を止めると、AIのパワーで全てが悪い方向に向かいます。 108
109. 余談：スキルなどは、目的で整理する • • コードと同じ。技術でまとめると散逸する。 やりたいこと。目的で整理していくと綺麗にまとまる。名前は大事。 109
110. 余談：噂ではgemini-3.7-flashの文章能力が高いっぽ い • • 中国系のTwitter民が騒いでいる印象なので、中国語だけ能力が高い可能 性はある 全然さわれてないけど気になる 110
111. 余談：claudeを学ぶなら公式のがある • • • 触ったことはないけど、日本語あるので、いいと思う 機能多すぎて正直自分も数ヶ月前に入った機能を今知るなどもあるの で、、、 https://academy.claude.com/ja 111
112. 余談だけでLT数本いけそう 112
113. 以上！！！ 113