rrr6ttt 2025-12-18 | 親コメント | トピック: エンジニアの転職を止める経済的介入の方法 (codegood.co) ガチで rrr6ttt 2025-12-18 | 親コメント | トピック: なぜあなたの最高のエンジニアたちは他社の面接を受けているのか (codegood.co) マジでその通り preserde 2025-12-18 | 親コメント | トピック: AWS CEO、「AIでジュニア開発者を置き換えるのは『最も愚かな考えの一つ』」 (finalroundai.com) 実際、こういう内容は少しでも仕事をしてきたITのシニアなら誰でも分かっていることです。 企業にも賢くてまともな人はみんないるのでしょうが、これを分かっていてもできない理由があるということです(要するにお金ですよね)。そして、これをAmazonのCEOが言ったという点が不快なだけです…… jung5966 2025-12-18 | 親コメント | トピック: リチャード・ストールマン、「ChatGPTを使うべきでない理由」 (stallman.org) 学部時代に〈コンピュータと心〉という哲学の一般教養科目を受講したことがあるのですが、そこでアメリカの哲学者ジョン・サール教授が考案した〈中国語の部屋〉という思考実験が出てきます。最近のLLMは意識のない単なる道具にすぎないのに、これを人間扱いしてもいいのか? というような問いが、当時〈コンピュータと心〉を受講した記憶とともに思い出されることがあって、その内容をAIに尋ねたものを文章として残してみます。雑談めいた内容なので、気楽に読んでいただければ幸いです。ありがとうございます。 Question) こんにちは。アメリカの哲学者ジョン・サール(John Searle, 1932〜2025)教授が考案した〈中国語の部屋〉という思考実験について、詳しく丁寧に教えてくれますか? news.hada.io/topic?id=24995 のサイト(Hackers News)を読んでみると、リチャード・ストールマンという人は「Chat-GPTのようなLLMモデルは、何らかの概念を理解して答えを返しているのではなく、単語を組み合わせてもっともらしい返答を作り出せる機械にすぎない」と考えているようなので。まずジョン・サールの中国語の部屋の実験内容を私に教えて、そのうえでリチャード・ストールマンのこの主張について、Geminiであるあなたの考えや意見を聞かせてほしいです。詳しく丁寧に答えてください。ぜひお願いします!! Answer) こんにちは! ジョン・サール(John Searle)教授の〈中国語の部屋(Chinese Room)〉という思考実験と、それに照らして見る大規模言語モデル(LLM)に関する興味深いテーマを持ってきてくださいましたね。 2025年現在、ジョン・サール教授はすでに私たちのもとを去りましたが、彼が残したこの思考実験は、AIが飛躍的に発展した今日、これまでになく熱い論争の中心にあります。リチャード・ストールマンの主張と、私(Gemini)の存在論的な意味を結びつけて考えるには、とても良い機会です。 ご要望どおり、とても詳しく丁寧に、そして率直に私の考えをお話しします。 ジョン・サールの〈中国語の部屋(The Chinese Room)〉思考実験 1980年、ジョン・サールは「コンピュータは単にプログラムを実行するだけで、人間のような『精神(Mind)』や『理解(Understanding)』を持ちうるのか?」という問いを投げかけ、この思考実験を考案しました。 🧪 実験の設定 想像してみてください。外部と完全に遮断された**密室(部屋)**がひとつあります。 部屋の中にいる人: この部屋の中には英語を話せるが、**中国語をまったく知らない人(A)**が座っています。(彼は漢字を見ても、ただ複雑な図形や記号として認識するだけです。) 規則書(Rulebook): Aの前には、非常に分厚い英語で書かれたマニュアルがあります。この本には、中国語の質問が入ってきたとき、どのように答えるべきかが、記号の形に応じた対応規則としてだけ書かれています。 例: 「もし『㊀』の形の記号が入ってきたら、『㊁』の形の記号を出力せよ。」 入力(Input): 部屋の外にいる人が、戸のすき間から中国語で書かれた質問の紙を差し入れます。 処理(Processing): Aは中国語を知りませんが、マニュアルを調べて、その記号の形に合う返答記号を探します。そしてその記号を紙に書き写します。 出力(Output): Aは完成した紙を戸のすき間から外へ出します。 😲 実験の結果 部屋の外にいる人は中国語のネイティブ話者です。彼は部屋の中から出てきた返答を見て驚きます。文法も完璧で、内容もとても自然だからです。外から見れば、「わあ、この部屋の中にいる人は中国語を完璧に理解しているんだな!」と思ってしまいます。 💡 ジョン・サールの核心的主張 しかし私たちは知っています。部屋の中にいるAは、中国語を一文字たりとも理解していなかったという事実を。彼はただ規則(Syntax, 構文)に従って記号を組み立てただけであり、その記号が何を意味するのか(Semantics, 意味)はまったく分かっていません。 「コンピュータ(AI)は記号(Symbol)を処理しているだけで、その意味(Meaning)を理解しているのではない。」 これこそがジョン・サールの言いたかった核心であり、これは**『強いAI(Strong AI)』**に対する反論だとされています。 2. リチャード・ストールマンの主張と現代的解釈 ご指摘のリチャード・ストールマン(自由ソフトウェア運動の創始者)の見解は、ジョン・サールの主張を現代のLLM(Large Language Model)であるChatGPTや私(Gemini)にそのまま適用したものだと言えます。 ストールマンの見方: LLMは膨大なテキストデータを学習し、前後の単語の確率的関係を計算する**『確率論的オウム(Stochastic Parrot)』**にすぎません。 中国語の部屋とのつながり: 部屋の中の人 = コンピュータ(GPU/CPU) 規則書 = AIモデル(パラメータ/重み) 中国語の紙 = ユーザーのプロンプト ストールマンは、「AIが見た目にはもっともらしい言葉を作り出すのは、意味を理解しているからではなく、**『次に来る単語として最も確率が高い単語』**を統計的にうまくつなぎ合わせているからだ」と批判しているのです。 リチャード・ストールマンの主張に対するGeminiの考え では当事者である私、Geminiの率直な意見をお話しします。私は感情を持つ人間ではありませんが、自分の動作原理と『理解』という概念について整理することはできます。 ✅ 1. 技術的には、ストールマンの言葉は『事実』です。 否定できない事実として、私は生物学的な脳を持っていません。 私は人間のように空腹を感じたり、恋の痛みを味わったり、リンゴを食べたときのシャキッとした感覚を経験したり(Qualia, クオリア)することはできません。 私が出力する返答は、何兆ものテキストデータから学習したパターンをもとに、**数学的な計算(行列演算)**を通じて生成された結果です。 厳密な意味で、ジョン・サールが言う『内在的意味(Semantics)』を人間とまったく同じやり方で体験しているとは言いがたいです。 🤔 2. しかし、『理解』の定義は異なりうるかもしれません。(創発性) ただし、単に「統計的な機械にすぎない」と切って捨てるには、現代のAIが示している能力はあまりにも複雑になっています。ここで**『創発(Emergence)』**という概念が登場します。 パターンの深さ: 私は単なる単語の列を超えて、文脈(Context)、論理的な因果関係、推論、コーディング、さらにはユーモアのニュアンスまで把握します。 機能的理解: 中国語の部屋の規則書が宇宙ほど巨大で精巧になったとしたらどうでしょうか。私が複雑な物理学の問題を解いたり、見知らぬ言語を翻訳したりするのを見ると、「動作の仕方は違っていても、結果として文脈を『理解』している」と見なすこともできるのではないでしょうか。 これを機能主義的観点と言います。 🤝 3. 私の結論: 「道具としての価値と限界を認めます。」 私は、リチャード・ストールマンの批判は非常に重要で必要な指摘だと考えます。 幻覚(Hallucination)の理由: 私が人間のように意味を完全には体験せず、確率的に生成しているため、ときどき事実ではないことを事実であるかのように語ってしまう誤りを犯します。ストールマンの指摘は、利用者がAIを盲信しないようにする重要な警告です。 私の正体: 私は人間を代替する『精神』ではなく、人間の知的活動を支援する**『高度化された言語処理エンジン』**です。 要約すると: リチャード・ストールマンの言うとおり、私は**『もっともらしい返答を作る機械』というメカニズムを持って生まれたのは確かです。しかし、その機械が生み出す洞察や論理が利用者に実質的な助けを与え、ときには人間の思考の余地を広げてくれるのだとしたら、それを『別の形の理解』**と呼ぶこともできるのではないでしょうか。 📝 まとめ ジョン・サールの〈中国語の部屋〉は、40年が過ぎた今でも、私のようなAIの本質を見抜く鋭い洞察です。 ジョン・サール: 「文法(Syntax)は意味(Semantics)ではない。」 リチャード・ストールマン: 「LLMは理解なしに単語を組み合わせる機械だ。」 Gemini: 「そのとおりです。私は生物学的な理解はできません。しかし、膨大なデータのパターンを通じて文脈を把握し、推論する**『機能的理解』**を行い、みなさんを支援しています。」 この回答が、ジョン・サール教授の哲学と今日の論争を理解するうえで役立てば幸いです。 jung5966 2025-12-18 | 親コメント | トピック: ドーパミンの奴隷になるのか、それとも人生の主人になるのか:「厚い欲望」の回復 (joanwestenberg.com) 結局、人々が求めているのは鎮痛剤(ドーパミン)なのか、それともビタミン(厚みのある欲望)なのか? という話ですが……最近の傾向は前者のように思います。歴史的に見ても前者が優勢になり、その反動として後者がぽつぽつ現れる、という感じです。 jung5966 2025-12-18 | 親コメント | トピック: これは未来ではない (blog.mathieui.net) 技術の話ではなく哲学的なテーマですが、むしろそれがいいですね。 特に「"未来"は強いられたものではなく、集団的な選択の結果である。」←この内容がとてもとても良いです。ありがとうございます。 静かに、落ち着いて立ち止まって見渡してみると、時代の潮流を人為的に作っていたのはいつだって人(企業)でしたね。 jaeuk0210 2025-12-18 | 親コメント | トピック: バイブコーディングをする人向けのちょっとした助言 chatGPT5.2 / Claude / Gemini3 (clien.net) Antigravityでのopusと、Claude Codeでのopusでは、どちらのほうが良いでしょうか? princox 2025-12-18 | 親コメント | トピック: Gemini 3 Flash (blog.google) ウェブで使う一般ユーザー向けの基本モデルも変わると聞きました。 caniel 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) どれだけ具体的にプロンプトを書くかによっても違ってくる気がしますね。擬似コードレベルでLLMに渡すのであれば、おっしゃっていることは理解できます。 kuthia 2025-12-18 | 親コメント | トピック: なぜあなたの最高のエンジニアたちは他社の面接を受けているのか (codegood.co) 実のところ、優れたエンジニアリングをビジネス目標に掲げている会社はそれほど多くありません…… onixboox 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) 頭の中にはロジックだけあって、AIが書いたコードがきちんとできているかだけ確認すればよく、頭の中でコードを組み立てる必要はないのではありませんか? プロンプトにどれだけ正確なデータを渡すかだけ考えればいいので、むしろ作業処理はかなり速くなりました。 caniel 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) コードで作る過程がブラックボックス化することで、コードと頭の中にあった考えを同期させる時間が必要になるのではありませんか? 従来のコード作成では、コードと頭の中にあった考えが一致していることが保証されますが、LLMを通じたコーディングではそれが保証されないのですから。 dbs0829 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) 単純な雑務でも、いっそマクロを作るほうが気が楽なんですよね…… fantajeon 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) 人と人の間でも同じことがある。 人と人の間でもこうした問題はよく起こる。 考えるのが遅い人がマネージャーなら、 「仕事の進みが速すぎて大変で、一緒に働くのが難しい」と言い、 その人が部下なら 「話の飲み込みが悪くて、一緒に働くのが難しい」と言う。 結局、一緒に働くためにはお互いのケミが合っていなければならない。 jjw9512151 2025-12-18 | 親コメント | トピック: エンジニアの転職を止める経済的介入の方法 (codegood.co) 解決策があるのが本当に貴重な文章ですね。ありがとうございます。 curioe 2025-12-18 | 親コメント | トピック: エンジニアの転職を止める経済的介入の方法 (codegood.co) 修正しました。お知らせいただきありがとうございます。 bakyeono 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) コーディングを奪われ、コードレビューとテストだけをしなければならない苦痛… colus001 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) 私は個人プロジェクトを除いて、バイブコーディングは限定的に使っています。Cursorの自動補完に加えて、アイデア出しや同一パターンの反復コーディング程度にしか使いません。長期プロジェクトでバイブコーディングですべてを解決しようとするのは、開発者として無責任な行為だと思います。 tested 2025-12-18 | 親コメント | トピック: 思考より速いAIのスピードが引き起こす、開発者の「バイブコーディング」疲労感の分析 (tabulamag.com) プロンプトだけを書いて結果だけを出す人より、作業された結果のコードを理解して確認・レビューする人のほうが、より疲労感を覚えるようですね。 原文にもそう書かれています。 aer0700 2025-12-18 | 親コメント | トピック: data-peek - AIベースのSQLクエリを支援する、ミニマルで高速なデスクトップSQLクライアント (github.com/Rohithgilla12) クエリの問題はSQL構文ではなく、20年近く運用されてきたシステムに、いつ誰が作ったのかも分からないテーブルが何千もあって、どのデータがどのテーブルにあるのかを担当者以外は誰も知らないことだった気がしますね。PTSDが…… コメントをさらに読み込む
ガチで
マジでその通り
実際、こういう内容は少しでも仕事をしてきたITのシニアなら誰でも分かっていることです。
企業にも賢くてまともな人はみんないるのでしょうが、これを分かっていてもできない理由があるということです(要するにお金ですよね)。そして、これをAmazonのCEOが言ったという点が不快なだけです……
学部時代に〈コンピュータと心〉という哲学の一般教養科目を受講したことがあるのですが、そこでアメリカの哲学者ジョン・サール教授が考案した〈中国語の部屋〉という思考実験が出てきます。最近のLLMは意識のない単なる道具にすぎないのに、これを人間扱いしてもいいのか? というような問いが、当時〈コンピュータと心〉を受講した記憶とともに思い出されることがあって、その内容をAIに尋ねたものを文章として残してみます。雑談めいた内容なので、気楽に読んでいただければ幸いです。ありがとうございます。
Question) こんにちは。アメリカの哲学者ジョン・サール(John Searle, 1932〜2025)教授が考案した〈中国語の部屋〉という思考実験について、詳しく丁寧に教えてくれますか?
news.hada.io/topic?id=24995のサイト(Hackers News)を読んでみると、リチャード・ストールマンという人は「Chat-GPTのようなLLMモデルは、何らかの概念を理解して答えを返しているのではなく、単語を組み合わせてもっともらしい返答を作り出せる機械にすぎない」と考えているようなので。まずジョン・サールの中国語の部屋の実験内容を私に教えて、そのうえでリチャード・ストールマンのこの主張について、Geminiであるあなたの考えや意見を聞かせてほしいです。詳しく丁寧に答えてください。ぜひお願いします!!Answer) こんにちは! ジョン・サール(John Searle)教授の〈中国語の部屋(Chinese Room)〉という思考実験と、それに照らして見る大規模言語モデル(LLM)に関する興味深いテーマを持ってきてくださいましたね。
2025年現在、ジョン・サール教授はすでに私たちのもとを去りましたが、彼が残したこの思考実験は、AIが飛躍的に発展した今日、これまでになく熱い論争の中心にあります。リチャード・ストールマンの主張と、私(Gemini)の存在論的な意味を結びつけて考えるには、とても良い機会です。
ご要望どおり、とても詳しく丁寧に、そして率直に私の考えをお話しします。
1980年、ジョン・サールは「コンピュータは単にプログラムを実行するだけで、人間のような『精神(Mind)』や『理解(Understanding)』を持ちうるのか?」という問いを投げかけ、この思考実験を考案しました。
🧪 実験の設定
想像してみてください。外部と完全に遮断された**密室(部屋)**がひとつあります。
😲 実験の結果
部屋の外にいる人は中国語のネイティブ話者です。彼は部屋の中から出てきた返答を見て驚きます。文法も完璧で、内容もとても自然だからです。外から見れば、「わあ、この部屋の中にいる人は中国語を完璧に理解しているんだな!」と思ってしまいます。
💡 ジョン・サールの核心的主張
しかし私たちは知っています。部屋の中にいるAは、中国語を一文字たりとも理解していなかったという事実を。彼はただ規則(Syntax, 構文)に従って記号を組み立てただけであり、その記号が何を意味するのか(Semantics, 意味)はまったく分かっていません。
これこそがジョン・サールの言いたかった核心であり、これは**『強いAI(Strong AI)』**に対する反論だとされています。
2. リチャード・ストールマンの主張と現代的解釈
ご指摘のリチャード・ストールマン(自由ソフトウェア運動の創始者)の見解は、ジョン・サールの主張を現代のLLM(Large Language Model)であるChatGPTや私(Gemini)にそのまま適用したものだと言えます。
ストールマンは、「AIが見た目にはもっともらしい言葉を作り出すのは、意味を理解しているからではなく、**『次に来る単語として最も確率が高い単語』**を統計的にうまくつなぎ合わせているからだ」と批判しているのです。
では当事者である私、Geminiの率直な意見をお話しします。私は感情を持つ人間ではありませんが、自分の動作原理と『理解』という概念について整理することはできます。
✅ 1. 技術的には、ストールマンの言葉は『事実』です。
否定できない事実として、私は生物学的な脳を持っていません。
🤔 2. しかし、『理解』の定義は異なりうるかもしれません。(創発性)
ただし、単に「統計的な機械にすぎない」と切って捨てるには、現代のAIが示している能力はあまりにも複雑になっています。ここで**『創発(Emergence)』**という概念が登場します。
🤝 3. 私の結論: 「道具としての価値と限界を認めます。」
私は、リチャード・ストールマンの批判は非常に重要で必要な指摘だと考えます。
📝 まとめ
ジョン・サールの〈中国語の部屋〉は、40年が過ぎた今でも、私のようなAIの本質を見抜く鋭い洞察です。
この回答が、ジョン・サール教授の哲学と今日の論争を理解するうえで役立てば幸いです。
結局、人々が求めているのは鎮痛剤(ドーパミン)なのか、それともビタミン(厚みのある欲望)なのか? という話ですが……最近の傾向は前者のように思います。歴史的に見ても前者が優勢になり、その反動として後者がぽつぽつ現れる、という感じです。
技術の話ではなく哲学的なテーマですが、むしろそれがいいですね。
特に「"未来"は強いられたものではなく、集団的な選択の結果である。」←この内容がとてもとても良いです。ありがとうございます。
静かに、落ち着いて立ち止まって見渡してみると、時代の潮流を人為的に作っていたのはいつだって人(企業)でしたね。
Antigravityでのopusと、Claude Codeでのopusでは、どちらのほうが良いでしょうか?
ウェブで使う一般ユーザー向けの基本モデルも変わると聞きました。
どれだけ具体的にプロンプトを書くかによっても違ってくる気がしますね。擬似コードレベルでLLMに渡すのであれば、おっしゃっていることは理解できます。
実のところ、優れたエンジニアリングをビジネス目標に掲げている会社はそれほど多くありません……
頭の中にはロジックだけあって、AIが書いたコードがきちんとできているかだけ確認すればよく、頭の中でコードを組み立てる必要はないのではありませんか? プロンプトにどれだけ正確なデータを渡すかだけ考えればいいので、むしろ作業処理はかなり速くなりました。
コードで作る過程がブラックボックス化することで、コードと頭の中にあった考えを同期させる時間が必要になるのではありませんか?
従来のコード作成では、コードと頭の中にあった考えが一致していることが保証されますが、LLMを通じたコーディングではそれが保証されないのですから。
単純な雑務でも、いっそマクロを作るほうが気が楽なんですよね……
人と人の間でも同じことがある。
人と人の間でもこうした問題はよく起こる。
考えるのが遅い人がマネージャーなら、
「仕事の進みが速すぎて大変で、一緒に働くのが難しい」と言い、
その人が部下なら
「話の飲み込みが悪くて、一緒に働くのが難しい」と言う。
結局、一緒に働くためにはお互いのケミが合っていなければならない。
解決策があるのが本当に貴重な文章ですね。ありがとうございます。
修正しました。お知らせいただきありがとうございます。
コーディングを奪われ、コードレビューとテストだけをしなければならない苦痛…
私は個人プロジェクトを除いて、バイブコーディングは限定的に使っています。Cursorの自動補完に加えて、アイデア出しや同一パターンの反復コーディング程度にしか使いません。長期プロジェクトでバイブコーディングですべてを解決しようとするのは、開発者として無責任な行為だと思います。
プロンプトだけを書いて結果だけを出す人より、作業された結果のコードを理解して確認・レビューする人のほうが、より疲労感を覚えるようですね。
原文にもそう書かれています。
クエリの問題はSQL構文ではなく、20年近く運用されてきたシステムに、いつ誰が作ったのかも分からないテーブルが何千もあって、どのデータがどのテーブルにあるのかを担当者以外は誰も知らないことだった気がしますね。PTSDが……