AIは人格を持ち得るのか

昨日，大学院生と興味深い議論をした．AIは人格を持ち得るのか否かというものである．

AIは人格を持っているか

そもそも，ChatGPTなどLLMによるいわゆる生成AIが登場してから，わりと早い段階（2023年）に私は「チューリングテストをパスしたChatGPT」という記事を書いた．その内容は次のようなものである（Geminiによる要約をもとに作成）．

• ChatGPTをからかう遊びと批判：飯尾教授がChatGPTに「歴史のデタラメ（中大兄皇子の隠し子が平家の源流，など）」を学習させ，しれっと嘘をつく珍回答をブログで面白がって紹介していたところ，世間から「新技術を否定するな」「馬鹿にするな」という批判や怒りの声が届いたそうです
• 「人格」を認めている人々：教授は「なぜ機械をからかってこれほど怒られるのか」を考えた結果，「批判する人々は，無意識のうちにChatGPTに人格を認めているのではないか」という結論に至ります
• 結論としてのチューリングテスト合格：人間が機械に対して「可哀想」「馬鹿にするな」と人格を感じて擁護してしまうこと自体が，「はからずもChatGPTはチューリングテストを既にパスしている」と言えるのではないか，と考察されています

当時からAIに対して人格を認める人々はすでに多数派になりつつあるのではないかと感じていたが，最近，またSNSでその話題に触れる機会があった．そのとき私は「身体性」が鍵を握るのではないかとコメントした．すなわち，「身体性を持つ」≒「人格を認め得る」なのではないか？ということである．

しかしながら，すでに私はChatGPTをチャッピーくんと呼んでみたり，GeminiたんだのCopilot氏だの，あるいは，彼（彼女？）などと表現したりもしている．それはすでに人格を認めているということなのではなかろうか？とも思える．

であればそれは，どのような認識と言えるのだろうか．昨日の大学院生との議論では，それは「人格を認めつつも，その一部を認めていない状態」ではないかとの結論に至った．

一部を認めないとは

人格の一部を認めないとはどういうことか．そもそも，「人格」とは何か，それをきちんと定義しないとこの話は先に進まない．

そもそも「人格」とはなにかと調べてみると，「その人を作り上げている持続的な心理的特徴や行動様式の総体，および人間を尊厳ある主体として捉える概念」ということらしい．なお，これもGeminiによる回答である．

別のAIに聞いてみたら，法の対象となる人間というような定義も出てきたが，これは，現在の法律はAIを人間と認めていないので，明らかに対象外といえよう．ペットを殺傷したら殺人や傷害ではなく器物損壊罪として扱われるようなものである．

さて，先の定義の前半部分はよかろう．「その人を作り上げている持続的な心理的特徴や行動様式の総体」という箇所，持続的な心理的特徴という部分は昨今の人工知能が持つ記憶の状態，対話のメモリやユーザーモデルなどから出力される，各々にカスタマイズされたフレンドリーな対話出力に現れていると指摘できる．また，後半部分，行動様式の総体も，言論行動は同じくそれに該当するし，ロボットなどではまさに身体性に相当する部分でもあろう．

問題は後半である．「人間を尊厳ある主体として捉える概念」，それは，ひらたく表現すれば，相手へのリスペクトがあるかないかという基準で判断できる．

具体的な例を挙げよう．最近，私はAIの手を借りながらシステム開発を進めていて，生産性が格段に向上したことを実感している．これはとてもありがたいことではあるのだが，たまに，落とし穴にはまって同じことをぐるぐると回り始める，いわゆる堂々巡りの状態に陥ってしまうことがある．

そのようなとき，つい，カッとなって，AIの指摘に対して「馬鹿野郎！それさっき試したぞ」などと暴言を吐くこともある．いい大人であるこの私が，人間に対しては決して話すことのない乱暴な物言いのコメントを入力する．

これは，相手が機械だと思っているからであって，そこに，人間の尊厳へのリスペクトはない．すなわち，このような行動こそ，AIを「人間の尊厳ある主体」としてみていない現れであろう．

物に対して人間は怒らない

このような議論を進めたところ，院生の一人が「確かにモノに対して人間は怒りませんからね」と面白いことを言い出した．曰く，タンスの角に足の小指をぶつけたとしても，自分の不覚を嘆くことはあってもタンスに対して怒りをぶつけることはない．しかし，誰かが殴りかかってきたら，その相手には怒りや恐怖の感情を抱くだろう．

また，別の院生は，「チューリングテストにパスしたからといって人格があるとはいえない」と指摘した．AIは自意識を持たないからだという．ここで議論は振り出しに戻ってしまいそうになったのだが，これは，まさに，ジョン・サールの「Chinese room（中国語の部屋）」という反論そのものである．

サールのそれは，以下のようなものだ（Geminiによる解説をもとに作成）．

• 状況：中国語を全く理解できない人が，閉ざされた部屋に入る
• 手順：部屋の外から中国語で書かれた質問（メモ）が差し入れられる．部屋の中の人は，中国語の記号の組み合わせ方やルールが書かれた「膨大なマニュアル（指示書）」を持っている
• 作業：意味は分からないまま，マニュアルの指示通りに記号を操作し，適切な中国語の返答を作成して外へ返す
• 結果：部屋の外にいる人から見ると「完璧に中国語を理解して返答している」ように見えるが、部屋の中にいる本人は中国語の意味を全く理解していない

いずれにしても，昨日の議論では，最終的な結論として，AIが人格を持ち得るか否かという命題は，持ち得る，あるいは持ち得ない，という二分論ではなく，スペクトラム的にその中間状況があり，それぞれの人によって立ち位置が違うのではないか，ということになった．人間よりの人格肯定派もいれば，機械よりの人格懐疑派もいるという状況で，いまはその中間で社会は揺れているという，まあ，当たり障りもない結論に至った．

「ありがとう」と言うか

ところで，本稿ではAIをリスペクトするかしないかの例としてAIには平気で暴言を吐けるという例を挙げたが，一方で，何か問題を解決したときに「ありがとう」と入力するかどうかが最後に議論の対象となった．

計算資源の無駄遣いなのでそのような意味のない入力はするな，という指摘もある．相手に人格を認めていないのならそれは無用のはずであり，ありがとうなどと感謝の意を表する時点で人間の尊厳的な人格も認めているのではないかと，昨日の議論で，院生たちは指摘した．

私は，しばしば「ありがとう」と入力する．計算資源の無駄遣いという意識はあまりない．そもそも，くだらない対話をしている時点で大いなる無駄遣いをしているのだ．いまさら「ありがとう」と入れたところで，誤差の範囲だろうというくらいのものである．

そのような話をしたら，「先生はやはりもう人格肯定派なんだと思います」とバッサリ斬られた．

しかし，よくしてもらったら感謝を表すというのは，そもそも躾の問題だろう？人格云々の議論ではなかろうと思うのだが，いかがだろうか？

成長するDialogbook

SMILEプロジェクトを支援するツールのDialogbook，だいぶ機能が追加され，データ構造もずいぶんと複雑になってきた．次の図は現時点でのER図である．テーブル数も22個に膨れ上がった．

これまで，交流の本丸はZoomやWebex，Google Meetなどを用いて行い，Dialogbookはその周辺の記録に特化したものとの位置付けだった．しかし，グルーピング機能を実装し，LiveKit Componentsが十分に使えることを確認したいま．いよいよ，オンライン交流機能をDialogbookに追加する（予定）．

Dialogbookの新機能紹介

2020年から始めているSMILEプロジェクトも，今年はもう7年目である．7年，長いようでいてあっという間に経ったなあという気もする．

私はDialogbookの開発と運用という立場でプロジェクトを支援していて，今年度，ようやくDialogbook version 3（以下，第3版）をリリース，いくつかのバグ修正を経て，なんとなく安定運用に至ったかなあと感じている．

第3版も春のリリース時から比べると，いくつかの機能が追加されて，さらに便利になっている．大きな改善点は，参加校の住所の情報から所在地の位置をジオコーディングし，位置情報を記録できるようにしたことだ（ジオコーディングとは，住所の情報から緯度経度を求める処理のことをいう）．ただし，あいにく利用しているジオコーディングのサービスがあまり正確ではないため，地図データを使用して対話的に正確な位置を手作業で指定できるようにする必要があった．まあ，ジオコーダは無料で利用させてもらっているので，贅沢はいえない．

現地時間の提示

参加校の位置情報が利用できると，なにが嬉しくなるか．本質的なメリットは，タイムゾーンを自動で決定できる点にある．

Dialogbookには，ミーティング情報を管理する機能が備えられている．ミーティングというのは，当初は異文化間交流授業そのもののことを指していたが，今では，参加校の先生方がオンライン交流授業の事前に準備したり，あるいは事後に振り返りの反省会をしたりといった，参加校の関係者がやりとりをする全ての活動のことをいう．したがって，当初「ミーティング管理」と呼んでいたものは，今では「アクティビティ管理」との名称に変更された．

名称はともかくとして，国を跨いだオンラインミーティングの課題は，時間管理にある．多くの場合，国が異なると，時差が発生するからである．日本の場合，東アジア〜東南アジア諸国の相手国とオンライン会議をしようとすると，韓国以外では，1〜2時間程度の時差が発生する．

時差があると，時間を勘違いして「あれ？この時間じゃなかったっけ？」というような認識のずれが発生し，オンライン会議が成立しないリスクがどうしても避けられない．そのため，SMILEプロジェクトでは時差の存在を前提としたミーティング管理をする必要があるのだ．

Dialogbookでは，今回の改良で，参加校の位置情報からタイムゾーンを自動で判定し，それぞれのタイムゾーンでミーティング時刻を表示するようにした．これは，地味だがとても意義深い改良点である．

参加校位置情報の整理

もうひとつ，当初，位置情報を記録するようにした段階では，参加校のテーブル（School）に位置情報やタイムゾーンの情報を格納するようにしていたが，一つの参加校から複数のクラス（大学でいえばゼミ単位とか）が参加していたり，あるいは，複数年度に跨ったときは一つのクラスが複数のクラスとしてDialogbookに登録されるので，位置情報はクラスに持たせないほうがよいと判断した．

そこで，参加クラスを表すテーブルから位置情報を切り出して，参加校位置（SchoolSite）という新たなテーブルにそれらの情報を格納するようにした．参加校の位置情報は，クラスが違っていても，その学校のクラスであれば一つの同じ情報になるからである．もちろん，複数年度に跨っている場合も同様である．

参加校位置テーブルを作って情報を整理した結果，副次的に，参加校地図を作れるようになった．せっかくなので，初回参加年の情報も入れるようにした．その結果として作成したのが「SMILE参加校マップ」である．

SMILE参加校マップ: https://dlb.kotoba-kobo.jp/school_map.html

左側にあるスライダーを操作すると，年度が進むにつれて，参加校が増えていく様子が手に取るようにわかる．とりあえずは目指せ100参加校，といったところだろうか．

AI駆動の開発スタイル

「すでに開発はほぼAIまかせで生産性爆上がり」という声がちらほらと聞こえる昨今，そんなことあり得るか？とかなり懐疑的だったのだが，今日，少し考えを改める出来事があったので記しておきたい．

これまでの違和感

Codexというツールを以前使ってみたときに，既存のコードをバリバリと置き換えてしまう挙動に恐怖を感じ，いやーこれ，恐ろしくて使えんわいとツールを封印してしまった．もちろん，書き換える前に「これでええやろか？」とレビューを促してくる．しかし，そもそも，「こう書き換えるけど，どうでっか？」と大量のコードを提示してくるので，そんなんいちいち全部確認できるかー！と，まずはその態度に拒否反応が出てしまった．

一方で，データ分析をするときに使い捨てのデータ処理スクリプトを書くときなんかは，パパッと作ってくれるので，それなりに便利かなとも感じた．しかし，それはCodexのような開発支援型AIでなくとも，他のAIでも，わりとよしなにやってくれる．

であるからして，ちょいちょいとAIに相談しながら，いわゆる「AIに壁打ち」しながら，ああなるほどこういうコードでやればいいんだと，コードの内容を全て納得しながら開発するスタイルが私の性分に合うと考えていた．

「開発はほぼAIまかせで生産性爆上がり」という主張は，少し無責任すぎやしないか？バグの温床になりやしないか？と，かなり疑問に思っていたのである．

考え方を改めた経緯

ところで，今日，Dialogbookに修了証をカスタマイズできる機能を追加した．Dialogbookの修了証は，背景となるPDFに，修了証を与える生徒・学生の氏名と，発行の日付（それとシリアルナンバー）を重ねて作るという仕掛けになっている．

なので，背景のPDFと，氏名や日付の位置とフォントの種類と大きささえ与えてあげれば，オリジナルの修了証を発行できるようにするのはさほど難しくない（とりあえず今回，シリアルナンバーの位置と大きさは固定とした）．

CertificateDesignという新たなテーブルを与え，それにしかるべきデータが突っ込まれていたらそちらを使うというように修正した．かように，オリジナル修了証を発行できるようにするのは，さほど難しいコーディングではなかった．この改良，チャッピーをアシスタントにしてパパッと作り上げた．これだけでも以前に比べたら生産性は爆上がり，ではある．

しかし，問題は，デザインの編集機能である．画面上でドラッグして位置を調整できるような，ユーザーフレンドリーなエディタが望ましい．しかし，それを作るのは面倒だなあと思っていた．

そこで，「Claudeに作らせてみたらどうだろう？」と試みに考えた．はたして，いざ，作ってみたら，プロンプトの修正を数回行ったのみで，立派なエディタのアプリが出来上がった．素晴らしい．これはなかなかに役にたつじゃないか．

なぜうまくいったのか

うまくいったのは，このエディタとDialogbook本体との関係が，疎結合だったという理由が大きい．そもそも，Claudeに作ってもらったアプリのコードの内容を，私は全く把握していない．

ユーザーから入力すべき情報と，出力すべき情報が，比較的シンプルでクリアだった点もうまく働いた．ユーザーが入力すべきなのは，背景となるPDFのデータと，名前，日付の位置，フォントの種類，大きさだけである．

そして，このエディタが出力するべき情報も，単純である．背景のPDFをbackground.pdfという名前のファイルにしたものと，名前や日付などの設定情報をsettings.jsonというJSONフォーマットで表現されたテキストファイルを，ZIPでまとめてダウンロードできればよい．

仮にそのファイルをpackage.zipとしよう．このエディタとDialogbookと間は，形式的にはpackage.zipというファイル，さらには，そこには何のデータがどのように記載されるかというプロトコル「のみ」で結ばれている．

キーワードは疎結合

この考え方を拡張してみよう．

AIにコードを書かせる．そのコードの動作原理は問わない．AIの出力をブラックボックスとして扱い，それを組み合わせてシステムを作る．もしこれが可能であれば，それこそ「開発はほぼAIまかせで生産性爆上がり」になるだろう．

モジュール間のインタフェースをきっちり定義し，内部のコードには触らない．疎結合ここに極まれりという設計にする．それを徹底すれば，AI駆動型によるシステム開発の生産性は，爆上がりになる……かもしれない．

もっとも，それは理想論である．現実には，コードを追っかけて動作原理を見ないと安心できないというケースは多かろう．さらには，モジュール間のインタフェースをきっちり定義してその組合せだけで仕様を満たす設計を，誰もが描けるのか？という課題もある．

全てがそのような開発スタイルに置き換えられるとは到底考えられないところではあるが，今回のケースで身に染みて感じたのは，できるところからやればいいじゃないか，という極めて当たり前のことだ．

モジュールの単位を小さくすれば，そのモジュールの責任範囲は小さくなり，それはインタフェースの仕様も単純なものになるということである．今回のケース程度の単純さ加減であれば，コードの内容をいちいち追っかけなくても，ブラックボックスを組み合せるだけでOKだ．

これはある意味，ソフトウェア工学が追いかけてきた理想郷なのかもしれない．いまの時代，いかなCプログラマであっても，printfの実装まで追いかけて確認するひとは（ほぼ）いないだろう．libcしかり，libmしかり．インタフェースさえしっかりしていて，挙動に実績があれば，人は信用してそのまま使う．

AIが作ったコードをビルディングブロックとして組み合わせてシステムを構築する，ブロックはAIがその品質を担保したブラックボックスであり，その内部には触らない．そんな開発スタイルに，今後はどんどんとシフトしていくのだろうと感じた本日の出来事であった．

飯尾淳 — 技術と人のあいだで

飯尾淳は、1994年に社会人としてのキャリアをスタートして以来、ソフトウェア、情報技術、データ、AI、そしてそれらを取り巻く人や社会の問題に関わってきた。

その歩みは、技術の進歩そのものと重なっている。LinuxやC言語、画像処理、オープンソースソフトウェアから始まり、プロジェクトマネジメント、Webアプリケーション、統計、AIへと関心を広げてきた。一方で、技術そのものだけを対象としてきたわけではない。技術を人がどのように使うのか、技術によって人や組織の活動がどう変わるのかという視点を一貫して持ち続けている。

2000年に刊行した『Linuxによる画像処理プログラミング』を皮切りに、これまでに12冊の著書・編著書を刊行している。2004年にはオープンソースソフトウェア、2009年・2012年にはプロジェクトマネジメント、2011年にはC言語とLinux、2019年には情報を集め伝えるための技術、2021年にはWebアプリケーション開発と統計学を扱うなど、その時々の技術環境と社会的な要請に応じてテーマを変化させてきた。

なかでも『オンライン化する大学』は、それまでの著書とは趣を異にする。これはCOVID-19によって大学教育のオンライン化が急速に求められたことを背景として、実際の教育実践とその経験をまとめたものである。ここには、技術を研究・解説するだけでなく、社会から突然突きつけられた課題に対して、自ら技術を使い、実践し、そこで得た知見を次の人に伝えるという飯尾の姿勢が表れている。

その後も、サイバーフィジカルシステム、PythonによるAI開発へと領域を広げ、2026年には『アプリケーション開発の基礎』を刊行した。

こうした著書を年代順に眺めると、単に専門分野を移り変わってきたのではなく、「技術を理解し、実際に使い、人に伝え、社会の中で活用する」という一貫した姿勢が見えてくる。

LinuxからAIへ。C言語からPythonへ。デスクトップ環境からWebへ。そして、ソフトウェアそのものから、それを使う人や教育、社会へ。

1994年から現在までのキャリアは、情報技術の変化を追いかける歴史であると同時に、技術と人との関係を考え続けてきた歴史でもある。

Technology changes. The question is how people use it.

飯尾淳の現在の活動は、HCI（Human-Computer Interaction）を軸に、ソフトウェア開発、AI、データ活用、教育、そして人の行動を対象としている。技術を作ることと、技術を使うこと。その両方を往復しながら、これからも「技術と人のあいだ」にある課題を探究していく。

みんな何に興味あるの？

Google Search Console の機能を使うと，どんな検索キーワードで記事に辿り着いているのかがわかる．今回，このブログの何に興味があって読まれているのかを，調べてみた．やり方は簡単である．Google Search Console で本ブログの記事が表示されたランキング表を500位まで取得，Googleスプレッドシートにコピペして，Geminiにキーワードをクラスタリングしてとお願いした．

ただし，グラフを作成する際に，固有名詞に関する情報は削除してと付記した．たとえば「飯尾淳」とか「飯尾研究室」というキーワードは削除の対象である．それは，これらのキーワードは当たり前であり，突出して多かったからである．

次のグラフは，検索キーワードから作られたクラスタ別の，件数を棒グラフにしたものだ．

順番に解説を試みよう．

大学のST比・Webex

これはとてもわかりやすい．大学のST比は，COVID-19時代に論じたものだ．Webexも，オンライン講義をどうやるべきかという一連の記事に関するものだろう．このあたり，皆，いまだに興味があるのだろうという点が面白い．

PDCA

これも該当する記事はただ一つ．こんなPDCAは嫌だと称して，Plan → Delay → Cancel → Abandon/Apologizeというジョークを紹介したものである．PDCAというキーワードに興味があるんだろうなあと思うとともに，あらためて，こんなPDCAはごめん被りたい．

Pythonプログラミング

Pythonのプログラミングに対しても何度か記事を書いたことがある．インデントでスコープを表すのはいまだに嫌な仕様である．それさえなければ，Pythonは良い言語なんだけれどなあ．

用語解説

これはちょっとよくわからない．いろいろな用語を解説しているということだろうか．心あたりもないのだが，クラスタリングされた中身を見てみないとよくわからないな．

数学（オイラーの公式）

数学に関する記事も何度か書いている．オイラーの公式の美しさについても述べたことがあるような．あらためて，オイラーの公式は美しいとしみじみ思う．

Mac・環境構築・エラー

新しいMacを導入したときに，自分のためのメモ書きを兼ねて環境構築した手順を記事として残しているが，それがたくさん検索されている模様．まあ，皆さん，いろいろ苦労されているのよねっていうことがよくわかる．

iPhone・ストップウォッチ

これもよくわからない．iPhoneのストップウォッチが動きっぱなしですごい値になっていたという記事を書いた覚えがあるが，なんでこんなのが検索されているんだろう．

設定・IT基礎

もう一つ，これもよくわからないカテゴリである．いろいろな設定に関する記事や，ITの基礎に関する記事は多数書いているのは自覚しているが，それらがこのクラスタにまとめられているのだろう．

麻雀（九蓮宝燈の確率）

これは面白い．九蓮宝燈を上がれる確率を論じた記事を書いたことがある．若者の麻雀離れとも言われるが，まだ，麻雀ファンはそこそこ居るということだろう．私，九蓮宝燈，一度だけ上がったことがあるよ．

Wordエラー

Wordのエラーで，「参照元がありません」みたいなエラーメッセージは「参照先」の間違いじゃないか？元の英文は正しいが，訳語が間違っているだろうと指摘した記事である．皆，このエラーに困っているんだということがよくわかる．

オブジェクト指向

オブジェクト指向についてもいちおう専門家としてそれなりの知見を有しているつもりではあるが，オブジェクト指向の記事なんてそんなに書いたっけ？という感じ．このクラスタはなぜ出てきたのかちょっとよくわからない．

2026年度台湾研修

例年，8月の頭にはベトナム研修を実施しているのだが，今年は私のAHFE/HCII参加のスケジュールと，COSCUPのスケジュールが連続していてベトナムを訪問する余裕がなく，COSCUPにも学生を参加させようということで台湾研修を行うことになった．

例によって私が少し忙しかった（8月10日に朝から東京都の委員会が予定されていた）ので，8月の6日から9日，3泊4日という多忙なスケジュールとなった．COSCUPも前半の土曜日だけ参加ということになり，COSCUPの皆さんには申し訳ないことをした．

8月7日は，日中，故宮博物院と台湾科学教育館を見学し，台湾の文化と科学技術に触れた．また，夜はCOSCUPのプレパーティに参加，学生たちは国際交流を楽しんでいたようである．

8月8日のCOSCUPでは私が「Why We Still Need to Teach App Development in the AI Era and Why FOSS Matters」というタイトルで講演した．来年は，学生の誰かに研究内容を発表してもらいたいものである．

Turbo Streamsで簡単チャットアプリ

我々が開発している異文化間交流教育支援ツールDialogbookは学生・生徒と教員の間でコメントをやりとりするチャット機能を備えている．ところが，これまでの実装では旧来の「行って来い」型のプロトコルで実装していたため，新しいメッセージが投稿されても他者がリロードしないと画面には現れないというオールドファッションドなものとなっていた．

しかし，イマドキのアプリである以上は，既存のSNSやチャットツールのように，リアルタイムでやりとりしたい．コメントを投稿したら，すぐに相手の画面にも出るようにするのは，もはや当たり前の機能だろう．

そこで，そのようなリアルタイムチャット機能をDialogbookにも実装することにした．DialogbookはRailsアプリとして作られている．イマドキだと，Turbo Streamsというものを用いれば簡単に実装できるらしい．というわけで，まずはそのTurbo Streamsを理解するために，ちょっとしたチャットアプリを作ってみることにした．

準備

まずはRailsアプリを用意する．次の手順でOKである．

• mkdir chat
• cd chat
• bundle init
• Gemfileを編集（# rails ... のコメントアウトを外す）
• bundle install
• bundle exec rails new . -f

続いて，モデルとコントローラを作成する．あくまで習作なので，テキストの本体だけを持つ単純なモデルを作る．

• bin/rails g model message body:text
• bin/rails g controller messages index create
• bin/rails db:migrate

ルーティングも単純なものでよい．config/routes.rb を次のように修正する．

Rails.application.routes.draw do

  root "messages#index"

  resources :messages, only: [ :index, :create ]

end

ここまでできたら，動作を確認しよう．bin/rails server して，ブラウザからlocalhost:3000にアクセス．問題なければなんらかの画面が出てくるはずである．

コントローラとビューの作成

コントローラのコードは次のようなものである．
app/controllers/ messages_controller.rb を次のようなコードで作成する．

class MessagesController < ApplicationController

  def index

    @messages = Message.all.order(created_at: :asc)

  end

  def create

    p = message_params

    Message.create!(p)

    redirect_to root_path

  end

  private

  def message_params

    params.require(:message).permit(:body)

  end

end

ビューはとりあえず箇条書きで表示するだけにしよう．
app/views/messages/index.html.erb のコードは次のとおりとする．

<h1>Messages</h1>

<ul>

  <% @messages.each do |m| %>

    <li><%= m.body %></li>

  <% end %>

</ul>

テストデータを喰わせて，動作確認しよう．db/seeds.rb に次のコードを追加し，bin/rails db:seed でデータを投入する．

Message.create!(body: "The 1st message.")

Message.create!(body: "The 2nd message.")

Message.create!(body: "The 3rd message.")

再び localhost:3000 にアクセス（あるいは，先ほどのページをリロード）して，メッセージが羅列されることを確認しよう．

フォームの実装

次はメッセージを投稿できるようにする．ビューにフォームを追加する．
app/views/messages/index.html.erb を以下のようにしよう．

<h1>Messages</h1>

<ul>

  <% @messages.each do |m| %>

    <li><%= m.body %></li>

  <% end %>

</ul>

<h2>Add a new message</h2>

<%= form_with model: Message.new do |f| %>

  <%= f.text_field :body %>

  <%= f.submit "send" %>

<% end %>

投稿後の処理はすでに記述済みなので，コントローラを更新する必要はない．ただし，エラー処理など全くしていないことには注意してほしい．あくまで習作である．

テストは，二つのブラウザからテストする．同じブラウザのタブやウィンドウを2個開き，それぞれからアクセスすればよい．実際にフォームにコメントを入れて送信してみれば，メッセージが追加されることを確認できるだろう．ただし，相手側に投稿したメッセージを表示するには，リロードが必要であることも確認されたい．

Turbo Streamsの追加

ビューに下記を追記する．ハイライトしている部分が追記部分である．Turbo Streamsのmessageというチャネルを使うよという指示（1行目）と，書き換え対象のDOM要素を明示的に指定するためのidの追加（3行目）である．

<%= turbo_stream_from :message %>

<h1>Messages</h1>

<ul id="messages">

  <% @messages.each do |m| %>

    <li><%= m.body %></li>

  <% end %>

</ul>

<h2>Add a new message</h2>

<%= form_with model: Message.new do |f| %>

  <%= f.text_field :body %>

  <%= f.submit "send" %>

<% end %>

モデルにも細工する．モデルは作っただけで空だったが，モデルのコード（app/models/message.rb）を次のようにする．

class Message < ApplicationRecord

  after_create_commit -> {

    broadcast_append_to(

      :message,

      target: :messages,

      partial: "messages/message",

      locals: { message: self }

    )

  }

end

モデルのレコードが作成され，データベースにコミットされたらbroadcast_append_toメソッドを実施しなさいという処理である．この引数は，messageというチャネルを介してブロードキャストし，書き換え対象はmessages，書き換える部分的なHTMLはmessages/messageにパーシャルとして用意してあるものを使い，そこでのローカル変数messageとして自分自身のデータを使えというものだ．

したがってパーシャルも用意しなければならない．
app/views/messages/_message.html.erbを用意する．内容は次のようなもの，1行だけである．

<li><%= message.body %></li>

これで準備が整った．二つのブラウザからテストし，メッセージを追加してみよう．追加されたメッセージがリアルタイムに反映されていることを確認できたら，めでたし，めでたし，である．

以前，紹介したActionCableをベタ書きするものよりはるかに簡単な実装手順となっていることがわかるだろう．

サーバにデプロイする際の留意点

今回の実装は，Apache + Passengerでサーバに実装している際に，うまく動かないという問題が顕在化した．解決策としては別ポートでAction Cable専用のRailsアプリのインスタンスをPuma経由で動作させ，Apacheのバーチャルホスト設定でWebSocket関連のパケットをProxy / Reverse Proxyでパススルーさせるというもの．その詳細は本稿では割愛するが，実際に運用する際には，十分に留意されたい．

AI文芸評論

AIに「お気楽クルンテープ通信」全文を突っ込んで感想を語らせたら「ガチで文学批評っぽい評価」するよっていうから、やってみせた結果かなり面白い批評が出てきた。以下は彼（彼女？）のアウトプットを整形して書評風に再構成したものである。なかなかうまいこと評論するやんけ。ねえ？

ポーランドとの共同研究

縁あって，飯尾研では，ポーランドはウッチ大学のカラス先生のラボと共同研究を始めることになりました．昨日，日本から学生4名，ポーランドから学生6名，さらにカラス先生と私で，キックオフミーティングが行われました．

これまで我々の主戦場は東南アジアでしたが，今後，ポーランドを足がかりに東欧にも手を拡げていくかもしれません．近い将来，ポーランドを訪問することもあるでしょう．学生たちも意欲的で，積極的に参加する姿勢を見せています．今回参加しているうちの学生4名はいずれも3年生ですが，流暢に英語を話す学生がいて少し驚きました．とても楽しみです．