AIのモデルの優劣とハーネスの組み合わせ
AIのめっちゃ優秀なモデルをガーッと使ったあとに、その下のモデルにちょっとハーネスを仕込んで使うと、なんかほぼ同じ事できるんですけど〜ってなった
これはなにか既視感があるなぁ〜って...
プログラミングセンスのある人に適当にお願いするとガーッと作ってくれるのと
プログラミングセンスは人並みの人がプロセスとドメイン知識をもってガーッと作る
この2つの違いかなぁ〜って思った
違いは、プロセスとドメイン知識をAIにわたすのは使う人だってことかなと
結果的にある程度優秀なモデル以上になると使う人の問題か〜ってなって腑に落ちた
このレベルのモデルがローカルで軽々動く時代になればいいのに...
AI習熟度と生産性とAIコスト
ふんわり周りを見ると、AIのトークンを大量に消費して大幅な生産性を上げてるヒトと、同じくトークンを大量に消費してるのにそこまでの生産性が上がらないヒトが居るような気がしてた
個人的にはわりと明確な基準通りに差が出てるので驚きはないけど、今後のことを考えるとAIへの適合性の有無ではなくそれなりに生産性を上げる必要があると思ってる
プログラミングだったら、なれるまで簡単な実装を担当して...とかで慣れたら少しずつ範囲を広げていくみたいなことが出来てたけど、AIはいきなりなのでその手が使えない
じゃあどうするかなぁ〜って考えてて、AIを使う型を用意して最初の頃はその型通りに使ってもらう、その型でちゃんと思い通りに行くようになってから工夫を加えていく
みたいになるのかなと思った
（AIDDでXXX流みたいにいろんな流派が生まれそうでそれはそれで楽しみでもある
まぁ何が言いたいのかというと、
clean/compactは適切なタイミングでやったほうがtoken消費は抑えられるし
あとは用途に合わせてmodelを選んだり、適切にsub-agentに任せたり
みたいなのを型として用意して、それを「身につくまでこの通りやりましょう」みたいにしていくとtoken効率上がるのかなぁ...
AIは人の能力を掛け算で引き出すだけじゃなくて、実は複利もある可能性...
1年くらい前に、AIは人の能力を掛け算してくるツールだと思ってた
それだけだと説明のつかない異常値をいくつも観測できてしまった
非エンジニアが普通に自分用のツールを作ったり
純粋な技術力という点を掛け算すると大きくズレる人が現れたり
h * AI = ある人がAIといっしょに出せる成果だと思ってたけど
h( 1 + r ) ^n + h * AI = ある人がAIといっしょに出せる成果
という風に考えないと成立しなくなって来てる気がする
h はその人が持ってる能力
r は何らかの倍率
n は何らかの回数
じゃあ、倍率と回数は何なのか？というのを観察してて...
回数は「試行錯誤した回数」
倍率は「試行錯誤した結果AIから追加で引き出せた能力」
と考えると、わりとしっくりくることに気がついた
AIをただ使うだけじゃなくて、試行錯誤してAIの能力をどうやって引き出すかを考え抜いた人が高い生産性を叩き出すんじゃないか...
というのが2026年5月時点の結論
1年後に違うことを考えてる可能性はあるので、現時点をメモしておく
ソフトウェア開発が装置産業になる日
最近の流れからの推測
2025年 ソフトウェア開発にAIの導入が本格的に始まる
ソフトウェア開発が人力で頑張ってた時代の終わりの始まりの年
これまでチャットツールだったAIが仕事をし始めた
2026年 ソフトウェア開発はAIと一緒にする時代になる
2025年にAI駆動開発とAIによるソフトウェア開発のノウハウが蓄積されて、遂にソフトウェア開発はAIが実施することが主流になる
ただ、この時点ででのAIは2025年の価格モデルだったため、AIを提供している各社は莫大な投資の割に利益が出ない状況が続く
202x年 ソフトウェア開発のためにはまずAIサーバを導入する時代になる
AIを提供している各社が最低価格付きの従量課金を開始。さらにオープンウェイトモデルの大幅な進化により通常の開発ならオープンウェイトのLLMで、高度な推論が必要な場合だけクローズドモデルみたいな棲み分けが始まる
オープンウェイトモデルを動作させるPCを各自に配布するよりも「自社用オープンウェイトサーバ」を導入してそれを活用する流れが起き始める
ソフトウェア開発の業務は、クローズドモデルを活用した仕様の作成とサーバへ渡すこと、それの結果の確認と次の指示出しが主な業務に変化する
結果
過去のPC1台あれば仕事ができた時代から、AIサーバの性能とモデルの性能とそれを使いこなす(使い倒す)技術が求められる時代に変わる
TPOに応じたAIサービスの使い分けなどが求められる
プログラミングに人がほぼ要らなくなるが、ソフトウェア開発の技術は必要
要件定義〜基本設計くらいまでのスキルの価値はさらに向上する
企業のシステム部門くらいである程度の社内サービスの開発・運用がAIの支援で可能になる
そしてこれらをサポートするサービスが立ち上がる（いまのSIerポジション）
運用時にはAIサーバで監視・障害の初動対応・アラート発砲を実施するようになる
従来コストが合わずに作れなかった社内サービスなども主にAIサーバの費用で作れるようになるので、ソフトウェアの数は膨大になる
エンジニアのAIの使われ方の分類 2026
エンジニアがAIをどんな風に使っているのかを観察してたら出てきた分類
エディタの延長
copilotとかのスゴイ補完ツールとしての使い方
この方法だと、生産性はそんなに上がらない気がする
トークン消費もそこまで多くないし、もう少ししたらローカルLLMで十分になりそう
部下として使う
AIに依頼して適切に介入する使い方
この方法が短期的には生産性を高く出来る気がする
部下として介入するまでの時間的余裕があるので並行依頼しやすい
トークン消費は並列数に依存するけど、めっちゃトークン消費する
先に色々用意したりツールを改善したり諸々必要
まるっと依頼する
ここ数ヶ月で特に増えた印象のある使い方
細かいことはよくわからないんだけど、問題なく作れる仕組みを使ってまるっと依頼する
コードのレビューもほぼしないし、ほぼ介入もしない
非エンジニアがもっとも使うやり方
ちゃんと運用できるところに持っていくまではそれはそれで大変
強力なツールとして使う
部下でもなく、適切に依頼しつつ適切に介入できる、強力なツールとして使う
他の3とは併用できる
AIだけじゃなく、AIを使う仕組みも含めた仕組みとして考えて新たなツールとして使う
思った以上にAIと周辺の仕組みを理解したりする必要があるのでなかなか大変そう
うまくハマれば生産性が最も上げやすくなる
まとめると
エンジニアの生産性を上げるのはコーディングとかだけの生産性向上だけだと駄目で、その周辺の全体の生産性を上げないと駄目
ということは、開発プロセスとソフトウェアアーキテクチャをAIを使う前提に合わせて変えていく必要がある気がしてる
ChatGPTとかの西野七瀬テスト
ChatGPTとか(BingAIとか)の特性として
大量の文章を記憶させてそこから文字列を紡ぎ出してるって言われてもよくイメージ出来なかったので...西野七瀬テストをやってた
西野七瀬テストとは
「西野七瀬について教えて」ってChatGPTに依頼した結果
本当の西野七瀬との差がどのくらいあるのかでChatGPTがどのくらい嘘をつくかを判断するためのテスト
GPT-3.5の場合は
元AKBとか、愛知県出身とかメチャクチャなことを言ってくるので、ある程度のグルーピングされた範囲内からそれっぽい文字列を紡ぎ出してる感が半端ない
GPT-4になると...めっちゃ合ってる！！
ということで、西野七瀬がセンターの曲とか、西野七瀬が出演したドラマとか深掘りしていくと...それっぽく紡ぎ出してるな...って感じになる
グルーピングの解像度が激しく向上した感じがよくわかる
BingAIに至ってはほぼ完璧(というか普通にソースも提供してくれるし)
なんだけど、あ〜ここは間違えてるなぁ〜みたいな感じになる
紡ぎ出すと言うよりも、検索してその結果をまとめてる感じ
という一見すると同じに見えるChatたちの動きの差を把握する為のテスト方法
西野七瀬みたいにだいぶ前から情報がそれなりに大量にあり
西野七瀬みたいに検索する人がそれなりに詳しく知ってる物
を利用するのがポイントなので、西野七瀬以外でも利用可能なテスト方法
西野七瀬テストをすれば良いのにって言ってもなかなか伝わらない(当然)ので公開w
ChatGPTの今の限界とかのただのメモ
ChatGPTを色々と使いまくった結果のイメージ
ネットから検索して正確な情報が欲しい場合はBingが役に立つ
学習の成長曲線の最初に居るときは、学習の助けになる
学習の成長曲線の終盤に居るときは、答え合わせが出来る(=自分がやらなくても出来る)
実務として始めた頃は、実務の助けになる(=自分がやらなくても...)
実務として慣れた頃は、実務の支援をしてもらえる(=自分がやらなくても...)
大量のコンテキストを前提として何かする場合は、役に立たない
世界でもレアな全く新しいことをやりたい時には、役に立たない
ポイントは、非常にレアなことをしない限りは常に役に立つ
役に立つ場面は大体こんな感じ
- たたき台を作る
- 整形する
- まとめる
ありがちなパターンを作るだけで良ければほぼChatGPTに任せた方が...ってなる
インターネットに情報として存在しない様なレアなものをやるってなった時点で初めて「役に立たない」ってなる
ただし、インターネットに情報として存在しない事と、存在してないことを知ってる事は全く別なので、確信がない限りまずは使ってみてそのレベルを把握してみる感じから始めると良さそう
ただ、大量のコンテキストを前提とする場合はその大量のコンテキストを前提を取り込ませたらそれなりに出来るのでは？？って思ってるので今後に期待してる
