DrupalCamp Tokyo 2026で印象に残ったプレゼンテーション。
LLMに適切な指示（プロンプト、コンテキスト、例）を与えて、ワークフロー処理判断を任せて100％の精度を叩き出し、社内処理の実運用の準備を整えた話。後刻登壇者にLLM自身がバージョンアップしたら動かなくなるのではないかと聞いたところ、LLMは変えないし、業務実施に十分なLLMであれば古くて安いものを使い続ければ良いとおっしゃっていた。同時に、そのLLMが利用不可になった場合のリスクがあることに触れられていた。
その後、自分なりに考えてみると、特定LLMの採用は新人の採用と同じなのだという考えに至った。ドメインエキスパート（先輩）が新人プログラマを指導してワークフロー処理判断のプログラムを書かせてもバグは出る。丁寧に指導して結果をチェックしてフィードバックしてやれば徐々に精度は上がる。人間であればワークフローのルーティング変更の仕方も学び、環境変更にも耐えられるように先輩プログラマが指導することも重要となるが、これもプロンプト（指示）を与えることに近い。人間と違って、時間が経過しても忘れたりしないだろうから、その分野での習熟状態が最も高まった状態がずっとキープできるわけで、病気にもならないし離職もしないから雇用者からすればありがたい存在になる。
学習のさせ方次第で同じ特定LLMであっても挙動が変わるわけだから、別の業務用のAIを育てれば良いことになる。業務担当からすれば、必要なスタッフの人員計画を行って、人間を雇うのか、LLMとプロンプト工数による投資を行うのかを天秤にかけることになるだろう。もちろん、そのプロンプトを生成できる要員を別のLLMを利用してAI代替を進めていくという形で人間を代替していくことになるだろう。
LLM競争は激烈で、いわば超賢い新人（AI）が供給されるようになってきたのが現状。一方で、人件費（ライセンス料）の高いAIを、その優秀性を必要としない業務に投入するのは無駄だ。CPUで言えば、今もZ80は現役で、8080でできることに64bit CPUは必要ない。古くて小さいLLMが無価値になるわけではなく、大して賢くないが、業務（人間代替）を任せるには十分なLLMには量的な需要があるだろう。賢さはそれほどでなくても実直なFOSS LLMが魅力的に感じられる日は近いのではないだろうか。
直井氏は、プロンプト指向プログラミングはDrupalの将来の姿だと表明していた（と私は理解している）。堅牢なコンポーネントが実現されれば、別にそれはPHPプログラムである必要はない（Drupalである必要もない）。Drupalベースのシステムでも、学習済みのLLMを含むContribution ModuleのConfig Entityを作成・編集することで所期の効果を得られるというサイトビルディングモデルは成り立ち得るだろう。
ドメイン知識に関しては、経験の足りない人は深さが足りないから適切なプロンプトを与えることは難しい。が、やがて人は引退するから、いずれ人的継承または機能や柔軟性、精度が犠牲になってもシステム化を行うことは避けられない。
システムに関わる人、持続性に価値を見出す人は、保守・運用に特段の注意を払うべきだろう。先端を追えば良いという話、あるいは先端を追っている人が偉いという話ではない。