ユーザー: oopに限らず関数型の方も式指向で高階関数多用くらいの意味の人と型が豊かであれそれ可能まで含める人もいたりするし、最近はもっぱら後者になってそう
AI: 仰る通りですね。プログラミングパラダイムとしての「関数型」という言葉が指す範囲は、ここ10年ほどでかなり高度な(あるいは厳密な)方へシフトしてきた印象があります。
コーディングエージェント、あるいはLLMを動かしているとき、ふと手工業的な手触りを感じることがある。たとえ最新のIDEを使い、高度な入力補完に助けられていたとしても、あるいは単一のエージェントに指示を出してその出力を待っている状態であっても、それが「ひとつ」である限り、どこか職人が手作業で彫刻を掘っているような感覚から抜け出せない。
もちろん、デバッグのように対象を凝視しなければならない場面で、処理が一つになるのは自然なことだ。けれど、もし平時においても人間が逐一監視し、次の手を指示しているのだとしたら、それはシステムによる製造というよりは、高度な道具を使っただけのクラフトワークに過ぎないのではないか。
本来的な意味でのエンジニアリング、つまり工学的なアプローチが立ち上がるのは、自分以外の何かが自律的に動き出し、しかもそれが複数同時に並走し始めたときだと思う。最低でも2つの並列処理が走り、それらが互いに協調したり、あるいは監視し合ったりしながら、全体として崩壊せずに秩序を保っている。そんな状態を作り出せたとき初めて、私たちは「書く」ことから「構築する」ことへと足を踏み入れるのかもしれない。
ユーザー: LLMで長文を生成する方法について教えてください。通常のaiサービスでは出力のサイズがある程度の長さに限定されてるような気がします。なので例えば章ごとに文章を出力しあとでマージする方法などについても考える必要があるかもしれません。また破綻なく作成するという意味合いでは画像生成の知見を利用できるかもしれません。再帰的な木のような形で領域分割しつつ破綻がないよう微調整を加えるという感じです。私を専門家と仮定して回答して構いません。
破綻のないマージを行うことについて考えてください。またどのような入力が必要かを考えてください。たとえば連載もののブログ記事や小説のようなものを品質高く作成することを考えてます。この場合はのり部分と既存のコンテキストを引き継ぐためのオーバーラップが肝になるかもしれません。
---
target_reader: ソフトウェアエンジニア、UI/UXデザイナー、およびデジタル環境における生産性と認知負荷の関係に関心を持つ実務家
objective: デジタルツールにおける「物理的制約の模倣(スキューモーフィズムの過剰適用)」が引き起こす非効率性を構造的に分析し、本来のデジタル生産性を享受するための「抽象化」の重要性を論じる
---
デジタルテクノロジーの本質的な利点は、物理世界の制約(距離、重力、物質の単一性など)から解放され、抽象化による高度な自動化や複製が可能になる点にある。しかし、人間の認知特性は、無意識のうちに物理的な手触りや空間的なアナロジーをデジタル環境に持ち込むことを好む傾向がある。
ここ数年、「新しいプログラミング言語やマイナーな言語を使うのはやめておけ、AIの支援が受けられないから」という意見をよく耳にするようになった。確かに、GitHub CopilotやChatGPTは、学習データが潤沢なPythonやJavaScript、あるいはRustのようなメジャー言語で圧倒的なパフォーマンスを発揮する。
けれど最近、本当にそうだろうか? と思い始めている。
学習データが少ない新興言語であっても、やりようによってはLLMを十分に活用できるのではないか。あるいは、そうした言語での開発体験は、私たちが思っているよりも早く「実用レベル」に達するのかもしれない。そんな期待混じりの思考を少し整理してみたい。