AIエージェント開発における指示の標準化とスキル管理
はい、趣味でOSSをやっている者だ。引き続き、twadaさんをゲストにお話ししていこうと思います。
はい、まあなんかあれですね、最近もうAIの話をするのがはばたられる時代背景もあるんですけど、もう今回は遠慮なくAIの話をしていこうっていう感じで進めておりますが、はい。
後半はそうですね、まずちょっとエージェントスキルとか、まあそういったところの関してブログを最近僕が書いたので、これについてこう話をしていきたいなというふうに思っております。はい。
なんかこう、ちょっとこれ書くの、前々から温めてたネタではあるんですけど、書くのが遅くなっちゃったなっていうふうにちょっと後悔していて、案の定あんまり読まれてもいないっていうところでがっかりしてるんですけど、はい。
まあなんかこう、なんか書いてることとしては、まずそのAIへの指示の仕方みたいなのが乱立してて、どこに何書けばいいのかわかんないとか、各ベンダーで違うから困りますよねみたいな話があって、まあなんかどこに何書けばいいかわかんないっていうのも、それこそ僕もお客様から質問されたりするんですけど、
最近は、そのエージェントMDだったりとかエージェントスキルズみたいなところの、まずこの2つを理解しておいて、そこをちゃんとメンテナンスしていけばいいんじゃないですかねみたいなのを書いてるのと、こういったものって結局ある意味現代の新しいソフトウェアスタックになっているので、
その1回作って終わりとか、なんか重厚頂戴なものを作って放置していくと、それはそれでなんか精度が落ちたりとか、そういう見えないふさい化していく可能性がありますよねみたいなことを書いてるっていう感じです。
なるほどなぁ、いや、よくわかるという感じですね、本当に。結構乱立っていうか本当に、なんていうの、ベンダーごとの方言みたいのもあれば、その1つのツールとかの中でも、なんかどこに書いてもいいみたいなところもあって、で、そういう時にそのどこに書くのがいいのとか、どこに明示するのがいいのとか、割とそうですよね。
なんか最初から追ってた人はだんだん機能が増えてくるから、まあなんとなくわかるところがあるんだけど、その後からそのコーディングエージェントとかを使い始めようっていうと、なんかいきなり設定できるものがいっぱいあって、しかもどこに書いてもいいですが、ここにはこういう意味がある、ここにはこういう意味があるみたいな感じで結構情報型になっちゃうとか、そういうのはありそうですよね、いかにも。
ありそうですね。流行りしたりが早いのと。それこそ、クロードだとスラッシュコマンドっていうのがあって、広報互換のために今も使えるんですけど、基本的には今はスキルズを使いましょうっていう流れになってるし、GitHubコパイロット、昔はプロンプツっていう、そういう指示の再利用のための置き場所があったんですけど、それもスキルズにしましょうっていうふうになってきてるっていうのがあって、
そうすると、その辺がやっぱごちゃごちゃしてるプロジェクトとかに入っちゃうと、なんかこれプロンプツとかスキルズとかスラッシュコマンドとかたくさんあるけど、どこに書けばいいのとか、クロードMDとかエージェントMDとかたくさんあるけど、これはなんなのみたいな感じになるっていうのがすごくあるんですよね。
なので、今はもうエージェントMDとエージェントスキルズを理解しておけばOKですよっていう、そういうようなお話です。
なるほど。確かにまずその2つから押さえていきましょうっていうのはまさに王道っぽい感じですよね。
結構そのスキルズも、どういうスキルを使うべきかとか、あとはどのくらいスキル化するかとかしないかとか、どのくらいスキルに頼るか頼らないかとかって結構ばらつきがあって、チームでもばらつきがあるし、そのチーム内の個人でも結構ばらつきがあるし、
というところで、割とスキルズの運用とか、運用っていうのはつまり何を選んで、どう使っていってもらうかみたいになって、意外と難しいねっていうのが結構僕は見てる各企業でぶつかってる壁みたいな感じですね。
そうですね。それは絶対あるでしょうね。それこそ会社によってはなるべくリポジトリ内に置きましょうっていう会社もあれば、だからもうあんまりリポジトリ内に置かないで個人のところに置いてしまいましょうっていう、そういうところに、その辺も難しいですし、
結局、今のスキルって、どうしても自分たちの都合みたいなものを、ある意味、何だろう、汎用的に作るのは難しくて、どうしても自分たちの用途に特化したものを作るほうが強力になるし、
何ていうか、無理に汎用して作ると作らないほうがいいので、そうするとじゃあ結構同じプロジェクト内でも、この人とこの人で状況が違うから、このスキルあんまり共有できないよね、みたいなのは起きちゃいますよね。
それは本当にそうだと思っていて、結構スキルをどんどん頼る人とあんまり頼らない人とかの違いを見るとか、そういうのいろいろ見たり、スキルもあんまり発動されないので意味のないスキルがゴミみたいに残ってるとかもあるし、
発動されたはいいけど、過度に汎用的で、あんまりプロジェクトにフィットしないっていうのもあったりするし、みたいな感じなので、僕、スキル自体は何ていうか、外からあんまり拾ってくるなっていうことを言ってるんですね、チームには。
で、それはいくつか意味がある。一つは単にセキュリティ的な観点なんだけど、どこの誰かが作ったかわかんないようなスキル、ちゃんと中身わかって入れてるのかみたいな、そういうよくある普通の話ですけど、っていうのもあるし、それより問題根深いのは外から拾ってきたスキルで自分たちのプロジェクトにフィットするやつってあんまないよねっていう。
さっきソムさんおっしゃってた、汎用的なスキルってよっぽど出来のいいやつじゃない限りは、わりとむしろ自分たちのモデルの良さを殺してしまうとか、自分たちのプロジェクトの状況に無理やり当てはめるみたいな感じになっちゃって、よくないよっていうことを言ってて。
なので、どこかから拾ってくるエージェントスキルで役に立つっていうものはほとんどなくって、そうじゃなくて、自分たちでチームとか組織でスキルを作って育てて、捨てる、いらなくなったら、というエージェントスキルのライフサイクルを辿れる力を組織とかチームとか個人とかがつけることの方がずっと大事だよっていうことを言ってて。
だから、どこかから拾ってくるスキルで一番役に立つのはスキルクリエイタースキルだよっていうことを言ってて、スキルクリエイターってエージェントスキルを作ることを手伝ってくれる汎用スキルですけど、それが一番どこかから拾ってくるスキルの中で使い道があるやつで、
自分たちの開発のやり方っていうのをどうやって仕組み化して育てていくかで、いらなくなったら捨てていくか、モデルが進化したらスキルっていらなくなるものも結構あるんですよね。
昔の1年前の基盤モデルだったらスキルで補わなきゃいけなかったんだけど、今の例えばフェイブルとかだったらこれスキルいらなくてない方がいい賞とするよみたいなやつはザラにあるので、ちゃんとスキルってやつは増え続けるものじゃなくて、どっちかっていうと減り続けるものだよみたいなことも結構現場で言ったりしてます。
いや、そうなんですよね。まさしく僕のブログでも同じようなことを書いていて、スキルクリエイター便利だよだけど、汎用スキルそんな使わない方がいいよっていうのを僕のでも書いてるし、ティーバダさんもそういうことをおっしゃってるのを見つけたりはしていましたね。
結局、周りの状況に応じて常識とか環境とか前提が変わってくるので、ある意味それを前提としたソフトウェアとしてこういうエージェントMDだったりスキルズを扱っていかないといけないなって思ってるので、それこそそこにあんまり定期的な見直しとか減らしていくみたいなことはしないと、
そこで実は品質の悪いアルトプットがずっと出続けてることに気づかないみたいなのが起きがちですよね。
なんかこれは結構ある意味新しい塞いっていうか、塞いっていう言葉が適切なのかわかんないですけど、そういったものになりつつあるなっていうのを感じてますね。
いや、本当そうだと思ってます。で、LMの基盤モデルとかがバージョンアップするときに、なんか結構プロンプティングガイドとかも変わったりするじゃないですか。
で、その時にスキルもやっぱり一旦棚卸しする必要があると思ってて、今使ってるスキルっていうの全部消してみて、で、そのモデルがどういう仕事をするかっていうのをちゃんと観察して、
で、それで足りないものをスキルとしてまた元に戻していくみたいな、なんか定期的にそういう棚卸しっていうのが必要だなと思っていて、
これってやっぱり新しいタイプの塞いっていうか塞いっていうか、あんまりこれまでにないタイプの道具ですね。
これまで僕たちって自動化の道具ってどっちかっていうと決定性の高いものを積み上げてきたので、
積み上げ式にどんどんどんどん自分たちの革新の度合いを高めるみたいな感じでやってきたんですけど、
なんか時代が進むとむしろいらなくなる道具をいっぱい作って、で、下手をするとそれをそのままにしてしまうことによって新しいモデルの良さを殺してしまうみたいな状況っていうのは、
あんまりこれまでソフトエンジニアの歴史ではなかったような状況、道具だなと思って、それやっぱり我々認識しなきゃいけなくて、
これまでCI、CDとかも含めて自動化の道具って資産みたいな感じで積み上げていけるものだったんですけど、
なんかそうじゃないんですよね。むしろ今足りないものを補うためにしょうがなく作ってるやつで、
もうなんか市販機に1回とか半年に1回とか捨てていかなきゃならないみたいな道具を日々作ってるっていうのは結構面白い。
面白いっていうかこれまでにはなかったタイプのものだなと思いながら日々いろいろ見たりしてます。
そうですね。サイクルが速くなっただけな部分もあるのかなと思ってて、やっぱクラウドとかが出てきた時も、
それこそ藤原さんが隙間家具みたいなことを言うように、隙間があればそこにものを作るけど、
エコシステム、プラットフォーム側がそこをカバーするような機能を出してきたら、それを取り外した方がいいし、そういうふうに作った方がいいよねっていうのも似た発想だと思うし、
それこそ自分たちで作った自動化スクリプトみたいなものも、プラットフォームとかSaaS側が便利なものを出してきてくれた方がそっちに頼った方がいいよねっていうのは元々そうだった部分はあると思うので、
それこそ今もLLMとかが便利になってるんだったら、そっちにもう委ねちゃった方がいいよねっていうところは変わらない部分もあるけど、ただチンプ化のスピードがものすごく速くなってるってとこがやっぱ違いというか変化なのかなっていう感じはしますね。
確かにな、構造は一緒なのか。確かにそうですね。スキマ株の話は本当にそうで、エージェントスキルもよく考えると2種類あるねっていう話をよく、これは僕が発案じゃなくて海外でもされていたものなんですけど、
そのケイパビリティスキルってやつとプリファレンススキルってやつにエージェントスキルは分かれるねと。ケイパビリティスキルっていうのはモデルができないことを補っていくタイプのスキルで、だから足し算のスキルで、プリファレンススキルっていうのは様々な選択肢がある中で自分たちのチームはこれが好みであるとかこういう流儀であるとか選択肢を狭めるタイプのスキル、
引き算のスキルみたいなもので、その前者のケイパビリティスキルっていうのはそのモデルのバージョンが上がったりしてモデルができることが増えると必然的に減っていく、いらなくなっていくものなんですよ。それまでの古いモデルができなかったことをスキルで補っているので、新しいモデルができるようになったらそのケイパビリティっていうものはもう新しいモデルは素で持ってるかもしれなくて、そしたら外しちゃったほうがいい仕事をすると。
それに対してチームのプリファレンスってやつはそのモデルの強さとはちょっと関係がないものだから、そのモデルがいかに良かろうと自分のチームとしてはその選択肢の中ではこういうものを好むとかこういう流儀であるみたいなところは引き続きそのモデルの設計判断に対して方向性を与えるスキルとしては重要であるみたいな感じに考えていて。
なので、自分たちのスキルってどっちなのかな、ケイパビリティスキルなのかな、プリファレンススキルなのかなみたいなのを考えながら棚卸ししていくって、3ヶ月に1回ぐらいちょっと一度ケイパビリティスキル消そうみたいな感じでやったりみたいな感じですね。
そうですよね。あと、それで思うのは、まだエージェントスキルズっていうのは仕様が発展途上にあるっていうふうに思うので、そういうプリファレンススキルみたいなものを組み合わせて活用するみたいなことが今やりづらいというか、具体的な話をすると、
例えば僕って自分のメモ用のリポジトリでそういうエージェントを動かすときに、エージェントにリサーチをさせますっていうときに、自分用のディープリサーチをしてくれるスキルを作ってて、それにリサーチさせてるんですね。
で、それどういうふうにやってるかっていうと、まずリサーチエージェントっていうのを呼び出して、その後、レポートまとめたやつをGitHubコパイロット、RubberDuckっていうのがあるので、他社のモデルとかでその内容をファクトチェックしてもらって、レビューを指摘して直して、レポートまとめあげるみたいなのをしてるんですけど、
これってやってることって、リサーチとファクトチェックの機能っていうのがあるんですけど、それって組み込みのコパイロットの機能を使ってるので、すごい階層型の依存関係になっているんですけど、
それってある意味、ソフトウェア的に設計的に考えると、リサーチ用のプリファレンスとファクトチェック用のプリファレンスを結構差し替えられるようになってたほうが、たぶん綺麗なソフトウェア設計だし柔軟で使い回しやすいソフトウェア設計にできるんだけど、今のスキルズって結局階層型にでかいものを作るときに指示を与えないといけないから、
だからすごい汎用的な、汎用的じゃない、こういうものにしか作れない作りになってるなって思うし、そういう依存性を注入して逆転させるって、ソフトウェアの仕組みってやっぱり強力だったんだなっていうのを改めて感じているみたいなのがあります。
たしかになー、その辺もありますよね。組み合わせるためのインターフェースがないっていうか、取り決めとかも含めてまだあんまりなくて、割とその辺手探りでやってるし、なんかそうですよね、組み合わせ難しいですね。
ソフトウェア的に考えると、やっぱりちゃんとインターフェース定めて、これ用のスキルを作ってくださいってなるんだけど、でもなんかそれって、こう、エージェント的ではない感じもするし、なんか、っていう、その、なんか、っていうのを持ったりしてますね、はい。
で、そうですね、なんか、この話もうちょっと続けると、やっぱり最近面白い変化だなって思うのは、やっぱりそのモデルが賢くなってきたので、これまで結構逐一、なんかこれはやってはいけませんとか、これとこれとこれを使ってくださいみたいな、割とそのマイクロマネジメントをするほうがいいよねっていうふうになってきたのが、なんか最近はそういうふうに、
そうすると逆にちょっと、なんていうか、コンテキスト、無駄なコンテキストが多くなっちゃって、精度が落ちるから、割とこうちゃんとゴールを伝えましょうとか、もっと軽量なプロンプトにしましょう、みたいな感じになってきているのが、すごくなんていうか、こう、なんていうか、メンバーの普通のマネジメントにおけるティーチングフェーズからコーチングフェーズに変わってきてるみたいなのをなんか感じていて、
いや、そこが今は面白いところだなって思ってますね。
たしかになー。なんか、部下のレベルが上がった感じですよね。
そう、そう思いますね。
結局、そういうマネジメントと、こう、マネジメント経験があると、割とそのエージェントを複数使うことの、なんていうか、そこの類似性を感じ取ることができるなっていうのは、ちょっと最近思ってはいて、
結局、AIと人間の知性の違いはどこにあるんだ、みたいな古くある議論がまた最近たまに見ますけど、結局、不確実なものを信頼するみたいな点では、割とAIもマネジメントも変わらないように通った部分があるなっていうのはすごい最近思ってますね。
SpecKitの限界と開発スタイルの回帰
はい。じゃあ、次の話は、スペックキット剥がしっていうのを持ってきてくださってますが、これはどういった話ですか。
じゃあ、それの話いきますか。スペックキット剥がしって別に特に、スペックキット自体に何か対話ないんですけど、スペックキットっていわゆるSDD系のツール、スペックドリブンディベロップメント系のツールの中でも結構重量級のツールなんですけど、
SDDっていうジャンルのツールが出てきたのは去年の夏終わりぐらい、秋ぐらいかなと思ってるんですけど、要するにスペックちゃんと使用を定義、がっつり使用を定義すると、そこをもとにコードを生成したり、
その使用書をシングルソースオブトゥルースとして扱って、そこからコードを生成していこうっていう、ちゃんと設計しよう、そこからコードを生成していこう、システムを生成していこうみたいな考え方のスタイルなんですけど、
それの代表的なツールの一つ、その世界を開いたのはAWSのキロというツールだったと記憶していて、そのキロが出てきてから、いくつかそのジャンルがSDDというジャンルが出来上がっていくつか出来た中の一つがGitHubのスペックキットというやつで、
僕もなので、AIとソフトエンジニアリングを研究するというのも去年からずっと追ってきてるので、SDKのツールも使おうっていうので、色々機能も使ってみたりしたんですけど、やっぱり一番がっつりしてるツールとしてスペックキット使ってみようというので、
使ってやってきたツールがあって、あれってどのくらい、もう半年ぐらいだから開発していると思うんですけど、先日そのスペックキットをやめて、普通というとあれですけど、GitHub Flowで開発して、
ドキュメントは、現役の設計は現役の設計のドキュメントに書いて、これまでの意思決定の過程のログみたいなやつはADR、アーキテクチャルディシジョンレコードっていう、よく使う設計の意思決定をためるフォーマットにしてやっていくぞというスタイル。
もうAIと一緒に開発をしていくときに、やっていたSDDの前にやっていたスタイルに戻したというのをやりました。これが先月ぐらいかな、今月頭かなぐらいなので、もうスペックキットに特に対応ないんですけど、
SDKのツールって結構、初期の設計というのをがっつりドキュメントとして蓄積して、特定のディレクトリにいっぱい書いていくみたいな動きをするんですけど、開発がもうそういうやり方で半年ぐらい進めていくと、初期に書いた大量のドキュメントと現在のソースコードっていうのがずれてくる。
それ良くも悪くもずれてきてしまって、じゃあシングルソースオブトゥルースはどこにある、今の設計っていうのはどこにあるんだっていうのと、あとこのプレリクエストにおいてどの範囲のドキュメントとどの範囲のソースコードをどう同期を取るべきかみたいなところが、だんだんだんだん扱いが難しくなってきてしまって、
本当はそういう場合にSDKのツールが目指していたのは、ドキュメントの方をちゃんと更新しましょうと、ソースコードはそこから再生成すればいいよみたいな感じのところまで求めていたんですけど、それやっぱり今はあんまりうまく動いていない、そこまで至っていないんですね。
再現性のある形でドキュメントからソースコードを生成する。だから、ドキュメントだけはたんなく更新していけばいいよっていうのが主の、やっぱり自然言語ベースのドキュメント、大量のドキュメントをはたんなく更新し続けるっていうのは、今難しいなって肌感覚になっていて、
なので、そういうスタイルで開発してきたシステムっていうのを伝統的なスタイルに戻したんです。伝統的なスタイルって何かっていうと、ソースコードは可能な限りきれいに書かれてるべきであると。
ソースコード自身がセルフディスクライビングってやつですね。ソースコード自身がドキュメントのように書かれている。保守性の高い、つまり理解容易性と変更容易性の高いソースコードになっていて、ドキュメントが必要がないぐらいきれいなコードであると。
その上で、コードでは絶対に書けないもの、ドキュメントにしないといけないものだけドキュメントにしていくぞ。ドキュメントじゃないと書けないのは何だっけっていうと、それがホワイト、ホワイトノットなんですね。
なぜこうしているのかっていうのと、なぜこうしていないのかみたいなところっていうのは、ソースコードにはなかなか書けないので、文章にきちっと書いていこう。
ホワイト、ホワイトノットを文章にためるという意味だとADRっていうのがそれに向いているフォーマットとして伝統的に存在しているので、そうしたらきれいなソースコードを書く。
もう説明が不要なぐらい、ドキュメントが不要なぐらいきれいなソースコードを書く。その上で、きれいなソースコードですらでさえ表現できないことをドキュメントにしっかり書く。
それが意思決定のログと、あと現役の設計がどうなっているかという方針し続けるドキュメント、その2つであると。
なのでドキュメントも追記型の、ADRっていうのは過去の意思決定のログだから、積み上げ型のひたすら積み重ねていくスタイルのドキュメントで、
あとは、スラドクス、スラデザインみたいな下にあるのは現役の設計で、それは機能追加されたりリファクタリングされるごとに更新されていく。
更新、上書き更新されていくドキュメントを、この2つをきっちり管理していく。
で、ソースコードはきっちりこれまで通り管理していくみたいな形にしたんですね。
というので、めちゃくちゃ普通の伝統的スタイルに戻して、だから最初にプランモードでがっつり議論して、
で、エージェントにコードをしっかり書かせて、きれいなコードになるまで徹底的に書かせて、
で、ドキュメントをきちんと更新して、そのセッションで私とAIの間で合意したこととか、新たに発見したことはADRにして残すみたいなスタイルに戻したんですね。
戻したときに、スペックキットで開発されてきたものを、クロードのフェイブルを使って、あたかも最初からそのスタイル、
意思決定のログはADRに貯めます。で、原液のドキュメントと意思決定のログだけをドキュメントに残しますみたいなスタイルで、
最初から開発されていたかのように時系列にADRを再整備するみたいな感じにしましょうみたいなので、がっつりやって戻した結果、
コントロールが戻ってきた。SDDでずっと開発していると、ドキュメントが増えすぎて、
人間側だとどこにどういうドキュメントがあって、どこに層があるかっていうのももうよくわかんないみたいな状況になっちゃってたのを、
どこに何があるかっていうのが全部ドライ原則に沿ってるみたいな感じになって、
原液の設計はここにあるし、Howの部分はソースコードとテストコードを見ればいいし、みたいな感じに戻ってきたらそのコントロールが自分の手元に戻ってきて、
結構大きめの、もう半年ぐらい開発してるから結構大きめのソフトウェアになっちゃったんですけど、コントロールを戻してきたみたいなところがあって、
これはやっぱり最近やった中だと印象的な仕事だったなと思ってて、
なんかその、何でしょうね、自分がそれまでやってきて、オープンソフトウェア開発とかでやってきたスタイルがやっぱり強くて、
で、その一種の王道だと思っていて、その王道を加速するためにこそAIを使うというふうにちょっとやっぱり戻ってきたなと、
This is the wayだなという感じになったので、それが最近結構リツイートされたりして、
みんななんかこのツイートを会う人会う人研究したりして、割と話題になってました。
そうですよね。いやーなんかこれ、やっぱり流派とか、自然言語が得意なのかコード書くのが得意かによってだいぶ分かれると思うんですけど、
で、僕も基本的にはT和田さんと同意だし、逆にT和田さんがちゃんとスペックキット試してたのが偉いな、さすがだなって思いました。
正直僕は使ったことないですですよねっていうのがあって、
結局、柔らかいものをマスターにする、大元にするの結構怖いなっていうところがあって、
それこそマークダウンをスペック、シングルソースオブトゥルースにするのって、
昔エクセルドキュメントみたいなものからデータベース定義書いてTDL生成してたみたいな、その頃の結構嫌な記憶みたいなのが戻ってきちゃう部分もあるし、
結局、固く書けるところは固く書いたほうがいいわけじゃないですか、それこそスキルとかもスクリプトにできるところはスクリプトにしたほうがいいし、
仕様とかドメインとかも、もちろんマークダウンでは書くけど、例えば形式変語的なものとか、テストとかで宣言的に説明できるのであればそっちにしたほうが絶対いいよねっていうのは、
僕もそう思っているが、なので逆にそのスペックキットとかを試してないのはある意味良くないなと思いつつ、Tワダさんがちゃんとそれをやったのはすごいなと思いました。
その辺はもう何でもやってみようというか、結構、割と去年の秋ぐらいの空気感としては、
自然言語によるプログラミングをさらに進めるみたいな、仕様駆動でどんどんやっていくんだよみたいな機運があったりして、
プログラマーとしての私は怪異的で本当かいなとか思いながらやるんだけど、本当かいなって思うからこそやってみようみたいな感じで、
割と自分が開発しているいろんなプロジェクトとか、あるいはいろんなツールとか、実際に本番のプロジェクトもあるし、そうじゃないパイロット的なものもあるんですけど、
なるべく違う道具をいろいろ使ってやってみようみたいな、いろいろ試してみようで、なるべく長期間いろいろ試してみようみたいなところがあって、
道具もいろいろ変えてみるし、リューハーもいろいろ変えてみるし、みたいな感じでやってた中の一つがそのスペックキットを使ってたやつ、それもやっぱり本当かなっていうのはやってみなきゃわかんないよねっていうのでやってみようっていうので、
自然言語だとちょっとやっぱ辛いかなって、だからこそじゃあ例えばもっと形式手法とかでもっと厳密めにやったらまた違う結果になるだろうし、
だからそれを試してみる価値はあるだろうしっていうのはありますね。というので一つの実験自体はあまりうまくいかないっていうのは別に失敗ではなくて、
そういうのがわかったから今のところは私自身が王道だと考えるスタイルに戻すのが良かったっていう話ですね。
ソースコードっていうのはその詳細な設計書と同等であるというような感じです。
そうですね、やっぱり疑ってたものも実は正解だったみたいな、何が起こるかわかんない部分もあるから、試されてるのは本当すごいことだなっていう、結局常識は変わるもんですからねっていう。
でもやっぱりちゃんと設計してからソフトウェア開発に移りましょうみたいなのって、実際のコード書きましょうっていうのは、まあそれはそうなんだけど、結局多分前半の話もあったように結局コードを書きながらわかってくるっていうことってあるので、
結局文章とかも文章を書いたら理解が深まるみたいなのもあるし、コードもコードを書きながら理解が深まって落とし穴に気づいて修正するみたいなのがあるから、
最近そこのAIがそこまでやってくれるから逆に人間は書きながら理解するみたいなことができなくなってるから、そこで置いてけぼりを食らうみたいなのはあると思うんですけど。
なので、ある意味、そこはまだ今のAIエージェントの限界の一つなのかもしれないんですけど、いくらちゃんと丁寧な計画とかスペックを練ったとしても、割とその後の開発で絶対ずれだったりとか、変更しないといけないことっていうのはたくさん出てくるよねっていう、そういうのは思ったりしてますね。
そうですよね。今おっしゃったように、前半の認知不細の話につながるんですけど、私たちって理解してからドキュメント書きましたっけとか、理解してから計画を書きましたっけっていうと、そうじゃないよねって話なんですよね。
理解してからコードを書き始めるじゃなくて、コードを書いている途中でだんだん対象を理解していくという順番だったので、それって別にスキルが悪いことではなくて、プログラミングって割とそういう側面があったんですね。
キーボードを通して対象をだんだんゆっくり段階的に理解していくみたいなところがあって、それがプログラマーの中の対象の世界に対するメンタルモデルの形成につながっていたんですけど、つまりコーディングっていうのは実は理解のフェーズだったというところなんですけど、
コーディングフェーズがまるっとなくなっちゃったので、なんかふわっとしてるんですよね。なんか地に足がついてないっていうか、AIと議論して分かった気になって、計画立てて、AIにやらせてみて、そうすると実際に始めてみると分かった気になったところと実際にやってみると違うっていうところのギャップがあるんだけど、
今のAI、能力が高まった結果、そのギャップを自分で乗りこなせるようになっちゃったので、人間にフィードバックが返ってこなくなって、人間はなんかふわっとした誤解のまま置いていかれる、置き去りになるみたいな感じになっちゃって、なんかまあまあまずいよなっていうのは思ってますね。
そうですね。そこはやっぱり難しい部分ですよね。でも結局、数式とかはそうであるように、プログラミングのコードとか、設定みたいなものって、ある意味そういう抽象的な、わかりやすくするための形式的な言語手法であるとは思うし、そのための新しい言語がまた出てくるかもしれないんですけど、
やっぱり数式使わずに全部言語で、自然文で解説できないように、やっぱり処理を明確に記述する手法としてコードっていうのはあるべきだよなっていうのは僕も思ってますね。でもそうですね、ドキュメントやっぱり増えすぎちゃう問題ってすごくあるので、そういう意味では多分ADRみたいなところにちゃんとそういう過去の経緯とかは残しときつつも、
多分そこを都度エージェントに読ませちゃうと多分おかしなことになっちゃうので、ちゃんと現状の仕様を別のドキュメントみたいなところに置いておきましょうっていうのはその理にかなってるなぁと思いました。
なんか、最近出てきてる他の話としては、やっぱりそういう意味で、とはいえその認知負荷がどんどん高まってきちゃっているから、人間がどう理解するかみたいなところだったり、現状、人間向けのドキュメントとAI向けのドキュメントみたいなのを分けるべきかみたいな話が、
人に優しいHTMLとPowerPointの再評価
出てきてると思うんですけど、なんかその辺りの理解をしやすくするための仕組みだったりとか、なんかやられてることとかって最近あったりされますか?
最近で言うと、よくXとかでも言われるようになってきたんですけど、そのHTMLを再評価するというか、ドキュメントとしてはマークダウンで書かせて、マークダウンでGitリポジトリにコミットするんですけど、
レビューをすると、設計のレビューをしたりとか、あるいはプルリクエストの中身の説明をさせるときは、AIにマークダウンを生成して人間がマークダウンを読むんじゃなくて、AIにHTMLを生成させて、HTMLを読みながらレビューする。
HTMLって言っても結構インタラクティブなHTMLを生成させて、人間はそれを読んでいくっていうのが、最近よくいろんな人がやるようになってきて、僕もそれをやっていて結構体験はいいんですよね。
というので、最近よくレビューはHTMLでやるようになりました。マークダウンでレビューするんじゃなくて、ビジュアライズされたHTMLでレビューするみたいな感じでやってます。
そう、それすごい便利そうだなと思っているんですけど、僕はまだやってなくて、これって具体的にそういうスキル的なもので、それ用のHTMLを吐き出させるみたいなことをやってる感じなんですか?
そうですね。特別なスキルがなくてもモデルがその能力を持ってるっていうか、例えば僕はよくクロードコードを使うんですけど、クロードコードのデフォルトで備わってるスキルみたいなやつですかね。
の中にHTMLで説明するためのスキルみたいなやつもあって、そうすると特別何かそのNORAのスキルをインストールすることなしに、これをもうちょっと図解してくださいとか、アニメーションっぽく説明してくださいみたいな感じで言うようになると、
HTML、特にパラパラ漫画みたいな図が、ボタンを押すと図が状態遷移していくみたいな感じの図が埋め込まれたHTMLみたいなのを生成してくれて、それでレビューするみたいな感じになっているので、デフォルトで割とそういう能力が備わっていて、
で、それがそういうやりとりが続いていくと、その人間としての私はどういう図による説明を好むっていうプリファレンスが出てくるので、そうすると私に対して図解するときにはこういう説明のやり方をとってくださいみたいなスキルを作って、最初からそれベースで説明してもらうみたいな感じで、なんかじわじわ育てていくというような感じですね。
なるほど、いいですね。そう、確かになんかそういう、やっぱり株足ない情報みたいなの、ソースコード、ドキュメントとかに詰め込んでおいて、必要に応じて人間がわかりやすいものをAIに出してもらうし、AIがそういうのを出しやすくしておくようにするのがいいのかなっていうのを僕はなんとなく最近思ってますね。
なんか、HTMLみたいなものって、それは一時的な資料みたいな感じなんですかね。
そうですね。これもなんかいろいろ小説あるみたいな感じですけど、僕はAIに生成させたHTMLっていうのはあくまで私に説明させるためだけの一時的な資料なので、
保存しないで捨ててしまうみたいな感じ。昔のセッションに撮ってあるので、捨ててないって言えば捨ててないんですけど、Gitにコミットしないっていうことは捨ててるも同然なので、保存はしていませんっていう感じなんですけど、
説明用の資料としてHTMLを生成させてGitにコミットするというスタイルの人もいますし、
あとは僕のOSSの開発とか、あるいは個人ツールの開発とかは、説明すべき人間が私しかいないから、生成して捨てるも自由なんですけど、
チーム開発してる場合は、一人が納得するだけじゃなくて、他の人にも同じような説明をしたいっていう形になるとHTMLを何らかの形でチームメンバーにも見せたいとか共有したいという形が出てくるので、
その時に大体ペラ一のHTMLなんですけど、どうやってチームレベルで共有しようかみたいな感じのところで、
いろんなインフラに共有したりみたいな、HTMLを単にAIが作った説明用HTMLを共有するだけのサイトをチームで作ったりしてるところもあるし、
クロードデータアーティファクトっていう仕組みを使って共有したりとかもあるけど、この間アーティファクト公開範囲の事故があったりして、
いろいろGoogleにインデックスされていたりとかそういうのもあったりするので、結構その良し悪しあったりするんですけど、
そのHTMLをチームで共有したいみたいなニーズっていうのは最近結構増えてきていますね。
そうですね、なんかそれ最近いろんな人がやっぱり話してる気がしますね。単なる静的HTMLをでもすごい簡単に認証をかぶせて公開したいみたいなことを言ってる人は最近よく見るようになりました。
まあそういう背景があったんですねっていう感じですね。
この話で言うと、最近僕の中である似た話として、パワーポイント再評価みたいなのが僕の中であって、これはたぶん仕事で使う機会がやをなしに増えたっていうのはあるんですけど、
でもパワーポイントってZIPでまとめられたXMLの塊集合なので、フォーマットとしてもオープンフォーマットなので、実はAIに編集させやすいぞだったりとか、機械的にも生成させやすいぞっていうのがあって、
僕は去年、慶一郎さんのデックっていうものにすごいコントリビュートして、マークダウンからGoogleスライドを作るっていうものを作ってたんですけど、結局、それって割と複雑なAPIを叩くし、それなりに作るのに時間がかかるものではあるし、そもそもGoogleスライドってオープンフォーマットではないから、
最近同じような、それをフォークしてパワーポイントを作ってもらうっていうツールを作ったんですけど、そしたら結構快適に動いているし、ある意味1回できたパワーポイントをまたAIに、ここの箇条書きをもうちょっと図にしてよみたいなことをやらせやすいので、これはちょっと便利だなって思ったりしてますね。
なるほど、なるほど、そうか。パワーポイントの方がどっちかっていうと、AIもいじり方を知ってるオープンフォーマットなんですね。
そうですね、そうなんですよっていうの。
し、それこそアンソロピックもそれをいじる用のスキルとかを出しているので、割とそういうのを連携させると、さらにいい感じにやってくれるみたいなのがあったりします。
はい。
AI脱臭問題と精神的負荷
あと他の話題としては、もう一つぐらいいこうかな。
やっぱり最近は、なんていうか、AIっぽい文章みたいなものをどれぐらい脱臭するかとか避けるかみたいな話が出てきて、ここは難しいなって思ってます。
なんかそれで、なんかAIで書かせて脱臭してもなんか本末転倒なんじゃないかみたいに思っちゃう部分はあるんですよね。
なんかその辺はちょっと議題上げてくださってますけど、なんかどう考えられてるんですか。
そうですよね。僕、最近特にそのAIに生成させた文章のAIっぽさを消すツールとかスキルとか、
なんか如実に増えているなみたいな感じだし、それを使っている人もだんだん増えてきてるなというような肌感覚なんですけど、
僕自身はそれはあまり問題解決になっていないっていうか、問題を根深くする方向に働くなと思っていて、
結構そういうAI臭の脱臭に関しては僕は否定的なんですけど、なんか構造上の問題があるというか、否定的なのは僕はそういうそのAI臭のある文章あるいは脱臭された文章を読む側に回ることが多いからで、
そうすると、例えばAI生成っぽい見た目のドキュメントってスルーすることができたんですよね。
AIっぽい見た目になっている時点で、問題はAI臭が問題なのではなくて、どちらかというと中身の無さっていうか裏付けの無さとか、
あるいは、なんだろうな、身体的経験の無さ、つまり書き手が実際には経験していないこととか、書き手が実際には考えていないことが文章の形になって出てくるということに起因する、
中身の無さっていうか、その真実の無さみたいなものが、やっぱり問題だと思うし不毛だと思うんですよね。
そうすると、そのAI生成っぽい見た目のドキュメントっていうのはスルーすればいい、あるいは期待値を低めにして読んでもいいということにもなるので、
生成した文章のAIっぽい見た目っていうのはシグナル、よくも悪くもシグナルだと思っていて、読まないというシグナルでもいいし、
ちょっと期待度低めにして、でも何ていうか読むべきところがあるかもしれない、みたいなシグナルかもしれないし、みたいな形で人間の方でモードの調整ができると思ってるんですけど、
その生成されたドキュメントのAIっぽい表現っていうのを消していくと、結果的に人間が書いた文章とAIが書いた文章の当たり前ですけど、
見た目上の差異がなくなってくるので、そうすると、あれこれ本当はこの書き手ってこれを経験していないんじゃないかなとか、
この書き手って本当はこんなこと思っていないんじゃないかとか、あるいは裏付けがないんじゃないかみたいなところに気づくのが遅れるし、
なんか常に疑念を持ちながら文章を読まなきゃいけないみたいな感じになっちゃうので、より疑心暗鬼が深くなるみたいな感じになっちゃってて、
なんか健全じゃないんですよ、すごく読み手側にシワ寄せがくるような構造になっていて、
結果、もうその長い文章の、なんか長い文章はすごい人間の書き手がすごい力を入れて書いた文章なのかもしれないし、
AIが1分で生成した文章をスキルで脱出しただけの文章なのかもしれないけど、それをこう読んで8割ぐらい読んで、
これ実はこの文章の中身がないのではって気づいた時のその不毛な感じっていうのがすごいんですよね。
僕自身はいろんな企業で技術顧問として、読書会とかあるいは技術文章を読み合わせる会、議論する会みたいなのをやってるんですけど、
最近は洋書とか書籍だけじゃなくて、ウェブ上の文章とかも話題になったものは全部翻訳しながら読んでみようとか、
そういったようなやり方をしているんですけど、そういった時にこのみんなで集まって1時間ぐらいいろいろ翻訳しながら読み合わせてみて、
45分ぐらい経った時に、これ実はAIスロップなのではって、AI生成したそれっぽい文章なのではって気づいちゃった時の、
集まってるみんなの不毛感とかがっかり感みたいのが落差がすごくてですね、なんかこれあまり幸せの構造じゃないなって強く思うようになりました。
なので、AIっぽさ、生成した文章のAIっぽさを脱出するとむしろ被害が大きくなるというか、構造は不健全になるというふうに思ってます。
はい。いや、そうですよね。僕もそれはそう思いますねっていう感じですね。
だから結局誰が書いてるかみたいなところがなんだかんだで大事になってる気もするし、でもそういう書き手もだんだんそういうこう、なんていうか、
ダークサイドに落ちてしまうみたいなことが最近起こり始めてるとか、そのAIに欠かせてるし、そこになんかそのAIに欠かされてるみたいな状況に陥ってるけど、あんまり自覚がないみたいな人も増えてるなっていう感じはしてますね。
いや、そうだと思います。すごく。
なんかちょっとそういう誘惑に駆られる気持ちもすごくわかるなっていうのはちょっと思ってて、僕もなんかその今回話題に挙げたこのエージェントスキルの話も、まあ割と丁寧に書いたつもりなんですけど、だからまあAIにレビューしてもらったりとか、
図を書いてもらったりみたいなのはしてるんですけど、むしろ書くのに時間がかかるようになったなっていう感じがしてて、そうすると余計そのなんか量産してる人とのスピード差がなんか増えちゃっているし、
そうするとなんていうか、自分が書きたいと思ってるものがその陳腐化するスピードみたいなのもなんか早くなってるので、そうするとやっぱりもうちょっとAIでスピードアップさせたいみたいな誘惑を持っちゃう部分ってあるなっていうのすごい感じではいますね。
なるほどなあ、なるほどなあ、それはあるかもしれないなあっていうのはありますね。
まあでも、たぶんこの前のゲストは川口さんなんですけど、川口さんのまだ現時点ではリリースされてない回で話したこととしては、やっぱり結構意識的に速度を緩めることとかが大事なんじゃないかみたいなことをおっしゃってて、
それは本当にそうだなあっていうのは思ったんですよね。
いや本当にそうだと思います。僕もそうだと思います。なので、意識的に速度を落とすとか、あるいは理解に通し、理解するために速度を落とすもそうだし、表現を深めるために速度を落とすもそうだし、
なんかここ2年ぐらいとにかくAIの物的生産性とかスピードにみんな当てられて、どうしても短距離性を繰り返すみたいな感じになっちゃっても、もうちょっとゆっくり深い思考をしてもいいんじゃないかっていうのはやっぱり思いますよね。
なんかそもそもそれってやるべきなのっていうところを、考える前に試せてしまうから、そうすると試してみてから考えようみたいな感じになると、ずっと実は試してるみたいな感じになっちゃったりとか、そういうのもあるので、
意識的に緩急をつける、スピードを緩めるっていうのはすごく大事だし、休むことも大事だなと思ってて、1日の中で休む時間を作るとか、常にエージェントを動かし続けるんじゃなくて離れる時間を作るとか、その辺やらないと人間の心の方が潰れていくよっていうのはやっぱり思いますね。
そうですよね、心が。やっぱなんか、これまでは肉体的なところにじわじわダメージがたまって結構腰が痛くなるとか、まあそういう、それこそティワダさんだと最近腕が肘が痛くなるみたいなのあると思うんですけど、
わりと知らず知らずのうちに、そういう脳への負荷とかメンタルの負荷みたいなのが積み重なって、どっかでドカッとくるリスクっていうのは今高まってるだろうなって思いますよね。
いや、そうだと思います。スティーブ・イェッキーがAIバンパイアって文章を書いていて、そのAIバンパイアみたいに自分たちは精神力をこう吸い取っていくので、それはなぜかというとAIと一緒に仕事をする時の強度が、仕事の強度、判断の強度が高すぎるので、
結果的に自分たちのその精神力というのはどんどんむしられていってしまうよと。なので、1日の労働時間をもっと短くしないとペース、維持可能なペースにならないよみたいなことを書いていて、結構そうだよなっていうのは思ったりしますね。
そうですね、本当そうだと思います。やっぱ今の8時間みたいなのも肉体労働ベースみたいなところでできた限界、コンセンサスだけど、やっぱこんだけ頭疲れちゃうと、実はもっと短い方がいいよねってのは僕も常々思ってるし言ってることではありますね。
夏休みとオーストラリア旅行
はい、まあそんなところで、お休みをされるということですよね、ティーワダさん。
そうですね、はい、ということで、今収録してるのは7月の最終日、7月31日で、で、あと10分で、あと実は8月になるわけですけど、8月は、去年僕1ヶ月8月休んだんですけど、
今年も休むぞって宣言して、1ヶ月8月はパブリックな活動、一応技術顧問業とかその辺は細々と8月もやるんですけど、いわゆる講演とか研修とか、
登壇とかパネルディスカッションとか、あるいはポッドキャスト収録とか、そういうのも8月はやらないって決めて、もう休むぞというふうにしたので、今年も休みます。
休むからこそ、ソンムーさんが急いで依頼をいただいて、7月中に収録しましょうっていうので、7月の最後の2時間で収録してるみたいな感じですね。
はい、収録できてよかったです。なんか海外行かれたりとかもされるんですか?
そうですね、海外に遊びに、海外旅行に行ったりとかしようというので、長く休んで、その時の体験に投資しよう、家族で海外に旅行に行ったりしようみたいな感じのこともやってて、
最近っていうか、去年行って体験良かったので、今年も行きたいなと思ってるのはオーストラリアで、オーストラリアって南半球にあるので、今冬なんですよ。
なので涼しいんですよね。だから8月めっちゃくちゃ暑い中で、南半球に行くと涼しいっていう体験がすごくまず良くって、
オーストラリアに行くと涼しいところがやや寒いぐらいみたいな感じっていうのと、あとイギリスの影響下にある文化圏にある国なので、車が右ハンドルで左側通行なんですよね。
っていうので、車借りて、キャンピングカーとかを借りて、オーストラリアってキャンピングカー文化なので、キャンピングカーをレンタルして、キャンピングカーで泊まれるキャンプ場、キャラバンパークっていうんですけどが至るところにあって、
キャンピングカーで旅をしてキャラバンパークに泊まって充電しながら色々料理作ったりご飯食べたりみたいな感じの放浪の旅をするみたいなのが結構体験としては面白くて、オーストラリアに最近ハマっていますみたいな感じですね。
体験がすごいいいんです。あとですね、時差がないんですよ。ないっていうか、時差1時間なんですよ。なので、これも結構ありがたくて、こないだサンフランシスコに行ったんですけど、やっぱ時差はすごくて、なかなか体にも心にも普段があるみたいな感じなんだけど、オーストラリアはその緯度は、緯度じゃないな、時差がほとんどない。
緯度がそうですよね。
緯度だけ違うので、そうすると。
緯度が違って、緯度が変わらない。
緯度が変わらないので、生活にあまりダメージがないんですね。っていうので、単純に冬になる、周りが冬になる。で、交通状況とかあんま変わんないし、全部Apple Payで決済できるしみたいな感じなので、結構体験としてはいいんですね。
治安も結構いいですし、英語が通じるしみたいな感じなので、旅行先としてはなかなか、夏休みの旅行先としては、いいな、結構体験いいなと思っていて、で、僕自身はキャンプも好きなので、そのキャンピングカー借りて、オーストラリアを長い距離旅するみたいなのもすごく面白いので、おすすめです。いい国ですって感じですね。
おだしょー 確かに、めちゃくちゃいいですね。車ないと、僕あんま車運転しないからそこがネックだけど、でも時差ないのいいですよね。僕も今、上司がオーストラリア人なんで、あんま時差なくミーティングできるのすごいいいなって思ったりしてますし、やっぱり今の日本のめちゃくちゃな夏を、本当に秘書できるっていうのはすごくいいですね。長期間いると良さそう。短期間だと簡単さで喰らいまくりそうな。
おだしょー そうかも。結構長く行くのはすごい良さそうですね。じゃあ間もなくあと5分ぐらいで夏休みに入るという感じになりますが、そんな間際の中に来ていただいてすごくありがとうございました。ぜひあのお休み、堪能してください。
おだしょー じゃあ今日はそんなところかな。ということで、趣味でOSSをやっているものだは、T和田さんをゲストに迎えて前回、今回とお話をしました。ありがとうございました。
おだしょー ありがとうございました。
次回もお楽しみに。
