  |
はてなキーワード: Pascalとは
経済学を学んできた人間として私が長年思い知らされてきたことのひとつは、技術革命についての予測はほぼ必ず二つの方向に間違えるということだ。短期的な影響を過大評価し、長期的な影響を過小評価する。Amara’s Lawと呼ばれるこの法則は、もう耳にタコができるほど引用されているが、引用している人々の大半がその含意を正しく理解していない。
なぜか。この法則が本当に言っているのは、私たちは技術の生産性への経路（path）を予測するのが絶望的に下手だということであり、それは「長期的にはすごいことになる」という楽観論の根拠にはならないからだ。むしろ謙虚さの根拠である。
1987年、ロバート・ソローが言った有名な一言がある。「コンピュータの時代はどこにでも見えるが、生産性統計の中には見えない」。いわゆるソロー・パラドックスだ。
結局のところ、ソローは間違っていた——ただし、正しくなるまでに約10年かかった。1990年代後半になってようやく、IT投資は全要素生産性（TFP）の統計に姿を現した。そしてその生産性ブームは2004年頃にはもう息切れしていた。つまり、真に生産性が加速した期間はせいぜい7〜8年だった。
ここで問いたい。AIについて、私たちはソロー・パラドックスのどの段階にいるのか？
私の暫定的な答え：まだ最初期、つまり投資は膨大だが生産性統計にはほとんど現れていない段階だ。2024年から2025年にかけて、米国の大手テック企業はAI関連の設備投資に年間2000億ドル以上を注ぎ込んでいる。これはドットコム・バブル期のIT投資をインフレ調整後でも凌駕する規模だ。しかしBLS（労働統計局）の生産性データは頑固に平凡なままである。
これ自体は悲観する理由ではない。1990年代の教訓は、GPT（General Purpose Technology、汎用技術——チャットボットの名前ではない）の生産性効果は補完的な投資と組織変革が追いついて初めて顕在化する、というものだった。電力についてのPaul Davidの古典的研究が示したように、工場が電力を最大限活用するには、建物の設計から生産プロセスまで全面的に作り直す必要があった。それには一世代かかった。
問題は、AIについてこの「一世代」がどのくらい圧縮されるか——あるいはされないか——である。
■ 今回は本当に違うのか
AI推進派（ブースター）たちの主張を整理しよう。彼らの議論は概ね三つの柱からなる。
第一に、AIは「知的労働」を自動化するので、過去の技術革命（肉体労働の機械化）とは質的に異なる。第二に、AIはAI自身の改良に使えるので指数関数的な自己改善が起きる。第三に、したがって従来の経済モデルは適用できない。
率直に言おう。第一の主張には相当の真実がある。第二の主張は経験的にまだ確認されていない。第三の主張はほぼ確実にナンセンスだ。
第一の主張から。確かにLLM（大規模言語モデル）がホワイトカラー業務の一部を代替・補完できることは明らかだ。コードを書く、文書を要約する、定型的な分析をする——これらのタスクでAIが人間と同等かそれ以上のパフォーマンスを示す場面は増えている。そしてこれらはGDP統計の中でかなりの比重を占めるセクターの業務だ。
しかし——そしてこれは大きな「しかし」だが——タスクの自動化と職業の自動化は全く別物である。これはDaron AcemogluとPascal Restrepoの研究が繰り返し示してきたポイントだ。ある職業の30%のタスクが自動化可能だとしても、その職業が消滅するわけではない。むしろ、残りの70%のタスク——AIには（まだ）できない判断、交渉、文脈理解——の相対的価値が上がる。
経済学ではこれを「Oの環理論（O-ring theory）」で考える。宇宙船チャレンジャー号を思い出してほしい。あの事故では、一個のOリングの不具合が全体を破壊した。多くの知的労働もこれに似ている。プロセスの大部分をAIが完璧にこなしても、人間の判断が必要な一箇所が全体の質を規定する。この構造がある限り、「AIが全てを代替する」というシナリオは実現しにくい。
投資の話に戻ろう。
私はバブルかどうかという問いの立て方自体が間違っていると思う。正確な問いはこうだ：現在のAI投資の期待収益率は、資本コストを上回っているか？
NVIDIAの株価は、AI関連の半導体需要が今後5年間にわたって年率30%以上で成長し続けることを織り込んでいる。Microsoftのクラウド事業の評価額は、企業のAI導入率が楽観的なシナリオの上限で推移することを前提としている。これらの仮定が同時に成立するためには、AIの経済的価値が、それこそ過去のどの汎用技術よりも急速に実現されなければならない。
これは不可能ではないが、歴史的な基準率（base rate）を考えれば、かなり強気な賭けだ。
もうひとつ、あまり議論されないが重要なポイントがある。AI投資の地理的・企業的集中度だ。米国のAI設備投資の大部分は事実上5〜6社に集中している。これは1990年代後半のテレコムバブルと構造的に似ている——大量の資本が少数のプレイヤーの「勝者総取り」の賭けに集中し、セクター全体の合理性が個別企業の楽観バイアスの総和によって歪められる。
マクロ経済的により心配なのは、バブルが弾けた場合の波及効果だ。テック企業の設備投資がGDPの相当部分を占めるようになった今日、AIへの期待の急激な修正は、2000年のドットコム・クラッシュよりも大きなマクロ的ショックをもたらす可能性がある。
■ 分配の問題
仮にAI楽観論者が正しいとしよう。AIが本当にGDP成長率を年1〜2ポイント押し上げるとしよう。それでも、私にとって最も重要な問いは変わらない。誰がその果実を得るのか？
過去40年間の技術進歩の歴史は、生産性の上昇が自動的に広く共有されるわけではないことを痛いほど示してきた。実際、skill-biased technological change（技能偏向的技術変化）の文献が明らかにしたのは、ITの普及が賃金格差の拡大と中間層の空洞化に寄与したということだ。
AIの場合、分配効果はさらに極端になる可能性がある。なぜなら、AIが代替するのは（少なくとも当面は）比較的高給のホワイトカラー業務の一部だからだ。パラドキシカルに聞こえるかもしれないが、配管工やクリーニング業者の仕事は、弁護士のパラリーガルやジュニアのプログラマーの仕事よりもAIによる代替に対して安全だ。これは分配の観点から複雑な含意を持つ——単純な「高スキル対低スキル」の図式では捉えきれない再編が起きる。
■ 私が本当に心配していること
以上を踏まえて、AI経済についての私の暫定的な見方をまとめよう。
AIは本物の汎用技術であり、長期的に有意な生産性効果をもたらす可能性が高い。しかし「長期的」が何年を意味するかについて、私たちは驚くほど無知である。現在の投資水準は、その効果が歴史的に例外的な速さで実現されることを前提としている。そしてたとえ楽観的なシナリオが実現しても、分配の問題が自動的に解決されることはない。
私が最も心配しているのは、AIについての公共的議論の質だ。テクノ・ユートピア主義者たちは「AGIが3年以内に来る」と叫び、テクノ・ペシミストたちは「大量失業が来る」と叫ぶ。そしてどちらの陣営も、自分たちの主張がきわめて不確実な予測に基づいていることをほとんど認めない。
経済学を学んだ人間として私が言えるのは、不確実性にはそれ相応の政策的対応がある、ということだ。セーフティネットの強化、教育と訓練への投資、競争政策による市場集中の抑制——これらは、AIがユートピアをもたらす場合でもディストピアをもたらす場合でも、あるいはその中間の（最もありそうな）場合でも、正しい政策だ。
確実性の幻想に基づく政策よりも、不確実性を認めた上でのロバストな政策のほうが、はるかにましだ。これは退屈な結論かもしれない。だが退屈な正しさは、刺激的な間違いに勝る。いつだってそうだ。
Delphiなら開発環境に付属するヘルプがとても充実しているはずだ。
Object Pascalそのものは、これまでのご経験があれば習得に大きな問題はないと思う。
どちらかというとDelphiはVCLというライブラリを使いこなしてこそなのだが、これの説明はヘルプがかなり役に立つ。
実は俺も20年以上前にDelphiの兄弟分であるBorland C++ Builder(BCB)というのを仕事で使っていた。
これもVCLが肝だったのだが、ちょっと慣れたら参考書なんて不要でヘルプでだいたい片が付くようになった。
膨大な内容だが、一度全体を目を通してみるのが良いだろう。
DelphiやBCBのユーザたちはメーリングリストで情報をシェアしあっており、悩み事があればその過去ログがよく検索でヒットして重宝したんだけど今は厳しいね。
メールアドレスが載っているので、自分だったらダメもとで連絡してみる。
こちらに関しては、会社に公式ドキュメントが残っているんじゃないだろうか。
20年前の、紙の資料がそれこそ山のようにあってもおかしくない。
ベテラン先輩に「会社の中にあるUNIFACEの公式ドキュメント全部のありかを教えてください」と言うのだ。
結構ちゃんとしている中小JTCなら、廃棄してないんじゃないかな。
これも出てきた文書すべてにざっと目を通せばとっつきやすさの順番がなんとなくわかるので、その順番どおりにじっくり読んでみるのをお勧めする。
望みはない気はするが、サポート契約してないかも念のため確認してみるといい。
サポート窓口が使えたら随分違うはずだ。
近頃のWeb記事や書籍はよく噛み砕いて初心者にも解りやすく書かれているから、元増田はそういう情報源じゃないと嫌なのかなと感じた。
確かに公式ドキュメントにそうしたフレンドリーさは期待できない。
特に慣れていない分野だったら最初の内は本当に訳わかんなくて読むのが辛いけど、理解できないうちは頑張って三度目を通そう。
眺めているうちに慣れていく。
絶対に助けになるはずだ。
ChatGPT:
はい、Delphi（Object Pascal）のソースも読めますし、解説・リファクタ・バグ箇所の指摘・他言語への移植案など対応できます。
VCL / FMX、Generics、Interface/RTTI、プロパティ/イベント、レコード・セット型、メモリ管理（string/AnsiString/UnicodeString の違い）、スレッド（TThread / TTask）、WinAPI/COM 呼び出し、uses 単位構成、.dfm（フォーム）やリソース周りもOKです。
コードを貼ってくれれば、1ステップずつ説明や改善案を出します（DelphiのバージョンやVCL/FMXも書いてあると精度上がります）。
UNIFACEはどう？
ChatGPT:
はい、UNIFACE（Proc言語）も対応できます。フォーム/サービス/レポート/エンティティなど各コンポーネントのトリガ（initialize, validate, leave field など）、operation／entry、newinstance/activate/call、retrieve/e, read, write、エラー制御（$status, $procerror）や論理名・assignment(.asn)、署名/パラメータ、DSP/REST・SOAP連携、DBドライバ設定までOKです。
コードや .asn を貼っていただければ、処理フローの解説、バグ箇所の指摘、リファクタ、他言語・他フレームワークへの移植案（例：REST API化、Java/Python 置き換え）まで具体的にやります。
可能なら UNIFACE のバージョン（9/10/10.4 など）、DB（Oracle/SQL Server 等）、OS を添えてください。
ゲーム用ではなく計算用途(HashCat、SD/NAI、llama.cpp etc…)のまとめ
Linux(もっと言えばArchLinux)で利用する(=できるスキルがある)ことを想定、購入手段は最低限AmazonとヤフオクとAliExpressが使えるものとする
増田の仕様用途はllama.cppがメインなのでそれにフォーカス。
| モデル | VRAM容量 |
| 7B q4_0/q3_K_M | 6GB |
| 7B q4_K_M | 8GB |
| 7B q4_K_M low-vram | 6GB |
| 13B q3_K_S | 8GB |
【メリット】
【デメリット】
【メリット】
【デメリット】
【メリット】
【デメリット】
【メリット】
【デメリット】
