昨今、AI時代の進化の速度は目を見張るものがある。
2022年にchatGPTが登場したその日以降私はLLMを触らなかった日はないと言っても過言ではないほどAIネイティブな世代だ。
4年前と比べ、ハルシネーションは大きく減り、その様相は大きく様変わりした。
もはやコーディング分野において、速度で人間がLLMに打ち勝つことはできない。
「こんな機能を作ってほしい」といえば大抵要件通りのものが出てくる。
Anthropicは2026/10/13にgitの代替として作成した社内バージョン管理ツールScionの発表記事にて1日30,000コミット(月ではなく日！)を行っていると言及している。
また、同記事の中で「エンジニアの仕事はClaudeにNoということだ」と述べている。
時代の流れは再びシンクラ(Thin Client)へ
昨今のクラウド・AI時代の流れの中で、私は再びコンピューティングがシンクラへ回帰していると感じている。
メインフレームの時代では手元のコンピュータのスペックが足りないために中央コンピュータがすべての計算処理を行っていた。
そこから分散コンピューティングの時代となり、我々の手元のPCに計算資源が移動してきた。
オンプレ構成が隆盛の後、東北大震災あたりを機に日本でもクラウド構成が徐々に普及し、データは我々の手元におかない構成が主流となっている。
Scionはgitの代替となるAnthropic内のバージョン管理ツールと先ほど述べた。gitはサーバーとクライアントで同じ動作を行っていますが、これだとクライアントが社内の30,000コミット/日に耐えられない。なのでサーバーでコミットを行うような構成にしたというものである。
つまり、「開発環境がオフラインからオンラインに移動しつつある」「これまでクライアント側で完結していた処理すら、オンライン前提でサーバー側へ移され始めている」ということだ。
昨今、CursorやCloudflare OSなど、クラウドでAIエージェントが前提となった開発環境がどんどんと出てきている。
時代が再びメインフレーム時代とは異なる理由で、クラウドにある計算資源を求めてシンクラ化している。
いずれ分散コンピューティングへと逆行するだろう
一方、巷ではローカルLLMというものも多く出てきている。
Qwen, Gemma, Kimi, Llama, DeepSeek, ... 様々なモデルが台頭してきている。
OpenCodeなるモデルのオーケストレーションツールもあり、AIハーネスを整える土台が着々と整いつつある。
AnthropicやOpenAIがLLM研究を主導し、これらのローカルLLMが後追いすることで現在のClaudeモデル並の性能を手にいれることとなるだろう。
そうなると我々の手元のPCにまたローカルLLMという豊富な計算資源が揃うこととなる。つまり我々の手元のPCでも、十分な性能を持ったLLMを利用できるようになる。
となるとクラウドに依存していた処理の一部を再びローカルへと取り戻す、分散コンピューティングの時代へ再度回帰する揺れ戻しの動きが強まることは想像に難くない。
では我々はどうすべきか？AI時代のエンジニアリングとは？
AIエンジニアリングを調べると
- プロンプトエンジニアリング -> 指示文をどう書くか
- コンテキストエンジニアリング -> AIに何を読ませるか
- ハーネスエンジニアリング -> AIの実行環境をどう整えるか
- ループエンジニアリング -> エージェントが自動で回り続ける仕組みをどう設計するか
の4つをまず目にする。
私はこれをみた時にまず持った感想が「なんだか会社みたいだな」ということだ。
会社というものは人をマネジメントするのによくできた構造をしている。
新人には研修を行い、「まずこんな感じで仕事をしてくださいね」という心構えのようなものを伝授する。
そして実際に現場で働く中で最初は具体的な指示を元に仕事する。
が、だんだんと「前に指示されたこれと同じようなことをすればよいのだな」と学ばせる。
そして社員はそのうち一人前となり自律的に仕事を行うことができるようになり、就業規則という社内ルールの元で毎回誰かに指示をされるでもなく動くようになる。
どうだろう、完全に流れは1-4のエンジニアリングの話ではないだろうか？
元々私はAIを使う上でのメンタルモデルとして、PMのようなものを想像していたが、最近はむしろそうではなく、管理職、ひいては経営層の視点でAIを使うことこそが肝要だと感じている。
AIには何をさせるかではなく何をさせないか
私は開発者であるためコードを例に取らせていただこう。
開発者の皆さん、このような感想を持ったことはないだろうか？
「うーん、数行の変更で済みそうな修正なのになんかいらん関数がいっぱいあるなぁ、、」
AIはよく過度な抽象化を行うことがある。ここはAnthropicも認めるところである。
たとえばコードベースで話すと以下のようなことである。
// 例えばユーザーのnameをバリデートチェック後にDBに保存したいとき
const name: string = "TESTER";
function save(_value: string): void {} // 保存関数mock
// 今回は空文字でないことをバリデートしたいとすると
// 1. AIがよくやりがちな実装
// DRY原則を重視しようとするあまり余計なヘルパーを切りがち
const isValid = (value: string) => {
return value !== "";
};
if (isValid(name)) {
save(name);
}
// 2. 欲しい実装
// ただ空文字でないことを保証したいだけなのでこれでよい
// ここで優先したい原則はDRYに基づいた抽象化でなくYAGNIチックな実装, KISSを最重要視したい
if (name !== "") {
save(name);
}
export {};
手でコーディングをしていた時代は皆が自然に2のようなコードを書いていたはずである。バリデートの詳細を詰めたくなったらその時にisValid関数を切ればよいだけだ。
そしてAIはこのようなAI自身の過度な抽象化によって自身のコンテキストを汚染してしまうことがある。本末転倒だ。
このような実装はクリーンアーキテクチャを誤解し、あの4層の図そのままの構成を実践しようとしてしまったようなコードによく本質が似ている。
あれの本質は「依存の向きを固定化しろ」ということのはずだ。
そしてこのような判断は「何をすべきか」というよりも「こうしてしまったらまずいことが起きるからこうすべきではない」という消去法的な判断がベースとなることが往々にしてある。
AIは「今目の前にある事項」を材料に教科書的なよりよい判断を下すことは得意とするが、それこそ文脈外、コンテキストの範囲外のことについて判断を行うことは非常に苦手である。
つまり「何をしないでおくべきか」という判断がとても苦手なのだ。
さて、先ほどの会社の話に戻ろう。新人は経験不足ゆえに「やってはいけない行動」がわからない。社会規範に通じていないので当たり前といえば当たり前である。
会社ではどのような対応がされているか。そう、「権限を渡さない」のだ。
いきなり会社の命運を分ける取引先に入社3日目の新人は連れていかない。すでに動いている業務システムのインスタンスを全て削除できるような権限をクラウド学びたての新人には渡さないだろう。
先ほどのような実装のブレはある程度Skillsを渡すことで抑制が可能であるが、そもそも「rmコマンドは実行させない」などの権限設定が肝要となる。
各エージェントに対してchmodを行わなければならないのだ。まさにITコンシェルジュのような役割だ。
余談であるが、最近自分はgit worktreeなどを活用して作業領域を分離し、AIによる変更を独立したブランチで開発を行うようなことをよくしている。
「AIの行動を信頼せず、出力結果に対して適切な検証を行うことで品質を保証する」ということだ。
これまでの議論を踏まえると、サブエージェント設計に対してもそれぞれのエージェントに対してどれだけの権限を渡せばよいのかがわかるはずだ。
会話履歴はSQLiteに保存する、その読み取りだけ行い過去の会話履歴を探索させるエージェントを作る、設計エージェントと連携させる、実装とレビューは分ける、実際の開発での役割分担と同じようなことを手元のPC内で行うのだ。
AI時代に本当に必要な能力とは
最後にこれだけ言及して本記事を締めたい。
これは明確に「言語化能力」「設計力」であろう。発想力や好奇心も大事ではあるが、こと「今目の前にある課題を解決する」という点においては課題点を洗い出してそれに対する対応策を論理立てて設計する力が何より求められるし、これはエンジニア以外の職種にも言えることである。
技術の移り変わりは早い、しかしそれぞれの技術が解決しようとしている問題の本質は大きく変遷するものではない。
そこを見極めることができれば技術の変遷を追うことは大きな苦ではなくなる。
このAI時代を生き抜くために最も必要な能力はそうした問題解決能力であろう。