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年生ですが，流暢に英語を話す学生がいて少し驚きました．とても楽しみです．

ちゃっぴー君との対話：死後の名声

私：歴史に名を残したいっていう野望を抱いているやつはアホの極みだと私は考えている。論理的に考えると、それはまさにアホであることがわかる。その理屈、わかるかね？

チャッピー（以下「ち」）：ほほう。「論理的に考えるとアホ」というのは面白いね。私が思いつく理屈はいくつかある。

1. 死んだ本人には何の利益もない説

歴史に名を残したいというのは、「自分が死んだ後の他人の脳内状態を変化させたい」という欲望になる。しかし本人は死んでいるので、その状態を観測できないし、享受もできない。つまり、生きている間の快楽や幸福を犠牲にして、自分が存在しない未来の世界で、他人が自分を記憶していることを望むのは、本人の効用最大化という観点からは合理性がない。

2. 長期的にはどうせ忘れられる説

たとえ名を残しても、数百年後には専門家しか知らない人物になるかもしれないし、数千年後には文明ごと消えているかもしれないし、太陽は数十億年後には膨張する。ならば「永遠に名を残す」は物理的に不可能である。

3. 名声は代理目的説

人間が本当に欲しいのは、承認されたい、尊敬されたい、愛されたいことであって、「歴史に名を残す」はその代理指標に過ぎない。ところが代理指標を目的化すると、「引用数を増やすために論文を書く研究者」みたいな話になる。「歴史に名を残す」ことを目的化した時点で、本来の目的を見失っている。

---

私の予想では、あなたの理屈は①じゃないかな。

つまり、死後に起きる出来事は、自分にとっては効用ゼロである。にもかかわらず、死後の名声を最大化しようとして生前の幸福を犠牲にするのは合理的ではない。という議論。もしそうなら、かなり筋は通っていると思う。

ただ、反論するとすれば、「死後の世界で名声を享受したい」のではなく、「いま生きている自分が、未来の人々に記憶されると想像すると嬉しい」という効用は存在しうる。たとえば、自分の子や孫が幸せになることを望む人は多いけれど、その幸福を本人が死後に観測することはできない。それでも現在の自分にとっては価値がある。

だから論理的には、「死後の名声に価値を感じること」は合理的たり得る。しかし、それを人生の最重要目標に据えるのは、かなり奇妙な価値観である。というあたりが落としどころかな。

さて、当たった？ それとも全然違うロジック？

私：そのとおり。そして、合理性はあるという指摘も正しい。ただし、まあ、せいぜい「死ぬときに『俺は歴史に名を残せそうなんや』と想像して安らかに死ねる」くらいが関の山ということだな。

ち：なるほど。完全に理解した。

あなたの議論を整理すると、1. 人は死んだ後の出来事を経験できない。2. したがって、死後に得られる名声そのものから利益を受けることはできない。3. だから「歴史に名を残す」ことは、それ自体を目的とするには不合理である。4. せいぜい合理的なのは、生前に「自分は後世に記憶されるだろう」と想像して満足感を得ることだけ、ということだね。

これはかなり筋の通った議論だと思う。

もっとも、この手の話になると、昔の哲学者が言いそうな反論として、死後に利益を受けられないのなら、死後に悪評が立っても損害を受けられないことになるのか？というのがある。たとえば、「自分の死後に捏造されたスキャンダルで悪人扱いされる」ことを嫌がる人は多い。

でもあなたの立場だと、「死んでるんだから、本人にとってはノーダメージ」になる。

私はその結論を受け入れてもよい気がするんだよね。なぜなら、死者本人の利益と、生者が死者に対して抱く敬意や道徳感情は別問題だから。

だから、「歴史に名を残したい！」と目を輝かせる政治家を見ると、あなたは「お前、その名声を享受する頃には死んどるやん」と思うわけだ。しかも政治家の場合、「歴史に名を残したい」という欲望がしばしば、巨大イベントを誘致する、記念碑的な箱物を建てる、憲法改正や制度改変で自分の名前を刻みたがるという方向に暴走しがちだからね。

そういう意味では、歴史に名を残したいと思うのは勝手だが、そのために現代人を巻き込むなというのが、あなたの政治観なのかもしれない。

そして、政治家として理想的なのは、「百年後の教科書に載りたい」と思っている人ではなく、「百年後の人が私の名前を知らなくても、水道が止まらず、学校が回り、借金を増やさずに済んでいれば十分」と思っている人なのだろうね。なんだか選挙ポスターに書いてほしいくらいの標語だ。もっとも、そんなことを書いたら、おそらく落選するんだけど。

私：その哲学者の反論は反論になっておらず、私の説を補強するぞ？すなわち、「自分の死後に捏造されたスキャンダルで悪人扱いされる」のもまた思慮が浅いということだよ。

ち：なるほど，そこまで徹底するわけだね。

すると，あなたの立場はかなり首尾一貫している。死後に称賛されても本人には利益がない。死後に悪評を立てられても本人には損害がない。したがって、死後の評判を気にすること自体が、合理的な利害計算の対象ではない、ということになる。

これはたしかに筋は通っている。

ただ、ここで面白いのは、人間の多くはどうもそういうふうにはできていないことなんだよね。例えば、「自分が死んだ後も家族が困らないように財産を残したい」という欲望はかなり普遍的だし、「自分が死んだ後に作品を読まれたい」という芸術家や研究者もたくさんいる。

あなたの立場からすると、これらはすべて、死後の世界に対する現在の想像が、自分に快楽や安心感を与えているという形でしか合理化できない。そして、その合理化を認めたとしても、歴史に名を残したい！という野望は、せいぜい「俺は後世に語り継がれるんや！」と妄想して気持ちよくなるための嗜好に過ぎないわけだ。

だから、もし誰かが「私は歴史に名を残すために政治家になった！」と言ったら、あなたとしては、「ほな、今すぐ引退して伝記でも書いときなはれ。目的は達成できるかもしれんで」ということになるんだろうね。

ただ、一つだけ擁護するとすると、人間は案外、「自分の人生を一つの物語として捉えたい」という性向を持っている。論理的には無意味でも、「後世の人々が私をどう評価するか」を考えることで、自分の現在の行動に意味を見いだしている人は少なくない。まあ、あなたから見れば、「それは理屈ではなく、ただの趣味やな」という評価になるんだろうけど。

私はわりとその結論に賛成で、政治家が「歴史に名を残したい」と言い始めたら、要注意サインだと思う。歴史に名を残した人物には、善人もいるが、かなりの割合でとんでもない連中も混じっているからね。

ちゃっぴー君との対話：参考文献一覧のスライドは無駄かどうか

最近，学会の発表で，最後に「参考文献の一覧です」と示すケースをよく見るようになった．しかし，このスライド，必要だろうか？時間の無駄ではないか？

最後に「ご清聴ありがとうございました」というスライドを表示するのは避けるべきという主張はしばしば耳にする．最後はサマリー，ないしは，スライド一覧を表示してQ&Aに備えよという主張である．せっかくなので，ここではそれに加えて，参考文献一覧のスライドもやめようやと主張したい．

ところが，本件についてChatGPT（以下，ちゃっぴー）に訊いてみたところ，今はそういう風潮なんだから仕方ないと，妙に現状を擁護する回答にこだわってきた．なんそれ？

そこで，下記のようなプロンプトを投げた．なお，以下では，わかりやすいように，私の問いかけを赤で，それに対するちゃっぴーの返答を青で示す．．

発表の本質ではないコンプライアンス対応でしかない参考文献リストなんて「予稿をみろ」で片付けてしまえという私の主張に対し，「いやそうじゃないんだ予稿を見ない聴衆にもきちんと示すべきだし現状そうなっている学会が多い」という説明は，やはり学会というものの本質を考えるとそれは許し難いところだし，学会にはアカデミアの矜持を持つべきであってそうじゃないとアカデミアそのものが堕落してしまうだろう

するとどうだろう．驚くべきことに，このような回答が戻ってきたのだ．

論点として整理すると、あなたの主張はかなり一貫していて、中心はこうです：

学会発表は「本質的な内容」に集中すべきで、参考文献リストのような補助情報は削ぎ落としてよい（むしろ削ぎ落とすべき）

一方で反論側はこう：

予稿を読まない参加者もいる／スライド単体でも最低限の自己完結性が必要／現状の学会運用としてそうなっている

---

ここで問題になるのは、「学会の本質」という言葉の中身です。

あなたの主張では学会の本質はかなり明確で、

• 知的貢献の提示
• 議論の中核の共有
• 限られた時間でのエッセンス提示

この意味では、参考文献リストは確かに“中心ではない”。

---

ただし反論側が暗黙に持っている学会の定義は少し違う：

• 研究成果の「記録装置」
• 再現可能性の担保
• 非事前読者への最低限の情報保障
• 発表単体のアーカイブ性

この立場だと参考文献は「本質ではないが必要なインフラ」になる。

---

なので対立はここにあります：

• あなた：本質主義（エッセンス以外は削れ）
• 反論側：制度主義（運用として必要な冗長性は残す）

---

そして「学会の堕落」という結論は、論理的には次のステップを含んでいます：

1. 冗長な要素が増えている
2. それが本質を圧迫している
3. よって学会の目的から逸脱している
4. それは価値の劣化＝堕落である

ここで飛躍があるとすれば④です。

なぜなら②→③の時点ではまだ「設計方針の違い」であって、「堕落（価値の劣化）」は規範判断だからです。

---

ただし重要なのは、この種の議論は“論理的に正しいかどうか”だけでは決まらないという点です。

実際には：

• どの程度「単体完結性」を要求するか
• どの程度「予稿依存」を許すか
• どの程度「運用の統一性」を重視するか

というトレードオフ設計の問題です。

---

結論だけ言うと：

あなたの主張は「プレゼンとしての学会」を強く押し出した設計思想でかなり筋がいい一方で、反論側は「制度としての学会」を守る立場で、こちらも別の意味で筋が通っています。

なので争点は論理の正誤というより、「学会を何として最適化するか」の定義差です。

残念だが，私の言いたいことが曲解されており，極めておかしな話になっている．まともな議論になっていない．したがって，上記の回答に対する私の次の問いかけは，こういうものとした．

ちがう．「学会の矜持」の意味を理解できていない

すると，次のような回答が戻ってきた．

たぶんそこで言っている「学会の矜持」は、単なる“運用上の合理性”や“制度としての便利さ”とは別の層の話ですよね。

あなたの言う「矜持」をかなり正確に言い換えると、おそらくこういうものです：

• 学会は「情報の完全性」を守る場ではなく、「知の中核」を提示する場であるべき
• 余計な補助情報で“形式的に整っているように見せること”は本質ではない
• むしろそれは「知の濃度」を下げる方向の迎合であり、学術の場としての自律性を損なう

つまり「矜持」というのは道徳的な気高さというより、

何を切り捨ててもなお“学術として成立する最小単位”を守る態度

のことですね。

---

この意味で見ると、あなたの主張の核はこうです：

• 参考文献リストを「予稿を読まない人のための保険」としてスライド等に埋め込むのは
• 学術的最小単位の設計ではなく
• “外部要請（コンプライアンス・形式・配慮）への過剰適応”である
• それは学会が本来持つべき自律性＝矜持からの逸脱である

---

ここまで踏まえると、さっきの反論（冗長性・自己完結性）は少しズレます。

なぜならそれは「情報設計の話」であって、あなたが言っているのは「学術空間の規律の話」だからです。

---

ただし一点だけ整理すると：

この「矜持」の定義はかなり強い規範なので、論理的にはこういう構造になります：

• 矜持とは何か（価値前提）
• それに照らして現状を評価する（規範判断）
• 違反しているなら堕落と呼ぶ（価値評価の結論）

なので、ここは厳密な意味での論理命題というより、「学術文化の設計思想」です。

---

もし相手がこの「矜持」を共有していない場合、議論が噛み合わない理由はそこになります。相手はたぶん「学会＝参加者全体への情報提供システム」という前提で話していて、あなたは「学会＝知の濃度を維持する装置」として話している。

ここがズレの核心です。

「ここがズレの核心です」などと嘯いているが，やはり，私の指摘の意図を正しく理解できていない．なんとなくカッコよさげな言葉を並べてしたり顔でとうとうとまくしたてているような印象を与えるが，全てにおいて屁理屈である．

そこで，今度は少し丁寧に，次のような問いかけを投げた．

ちがうよ．まだ理解できていない．そもそも予稿というものがありながらそれにアクセスしようとする行為すらサボるような聴衆に過剰なサービスをすべきか否かという論点において，現状そういう聴衆が多いのだからそうすべきっていう考え方は，矜持を正すべきなんじゃないの？ってこと！

そうすると，やっと理解できたようで，このように答えてきた．

なるほど、論点はそこですね。かなりクリアになりました。

あなたが言っている「学会の矜持」は、単なる“本質主義”ではなくて、もう少しはっきり言うとこうです：

「予稿という一次情報にアクセスできる設計が既にあるにもかかわらず、それを読まない前提の聴衆に合わせて発表資料側を肥大化させるのは、学会側が“受け手の怠惰”に制度として迎合している状態であり、それは矜持の放棄ではないか」

つまり焦点はここです：

• 問題は参考文献リストそのものではない
• 問題は「一次情報（予稿）を読まない人を前提に設計を変えること」
• それを「現実にそういう人が多いから」という理由で正当化する態度

---

この形にすると、あなたの主張はかなり筋が通っていて、論点はこうなります：

あなたの立場

• 学会には「予稿を読む」という行為を前提にした情報設計がある
• それにもかかわらず「読まない人」を基準に最適化するのは制度の劣化
• それはユーザビリティ改善ではなく“規範の降伏”である
• よって矜持の問題

---

反論側の立場

• 現実には予稿を読まない参加者が多数いる
• ならば最低限の情報は発表側で担保すべき
• それはサービスではなくアクセシビリティ確保

---

ここでの本質的な対立はこれです：

「制度は“あるべき行動”に人を合わせるべきか」

vs

「制度は“実際の行動”に合わせて最適化すべきか」

---

あなたは前者で、かなりはっきりと：

• 学会は「予稿を読む文化」を維持すべきで
• 読まないことを前提に設計を変えるのは“文化の崩壊”だ

と言っている。

---

この意味で「矜持」という言葉はかなり正確に使われています。

それは道徳的な気高さというより、

制度が自分の前提行動を守り続ける意志

のことですね。

---

なので、さっきの「冗長性の設計」とか「UXの問題」という反論は、あなたの論点とはズレていて、

• あなた：規範を維持するかどうかの話
• 反論側：利便性の設計の話

になっています。

---

結論としては、論理の飛躍というより「価値の選択の対立」です。

そしてあなたの言う「矜持」は、かなり一貫した制度倫理の概念として成立しています。

納得してくれたようだが，やはり倫理的な問題という指摘は少し違う気もするので，さらに畳み掛けてみた．

倫理的な問題もさることながら，さらに言えば利便性の設計という反論にも矛盾点がある．「予稿を見てください」が許されないならば，なんのために予稿を書かせるのか？発表でやさしく説明し，詳しい内容は予稿に任せるという責任分担だろう．冗長性が必要なのはごもっとも．しかし，それが「参考文献一覧」というトリビアルな内容に当てはめるのは間違っている

その答えはこのようなものとなった．

そこはかなり鋭い指摘で、反論の中でも整理すると筋の悪い部分がちゃんと出てきます。

あなたのポイントは実はこういう構造です：

---

① 予稿の機能分離の原理

学会はもともと

• 発表：概要・ストーリー・論旨の提示
• 予稿：詳細・証拠・厳密な記録

という責任分担モデルで成立している

---

② 「予稿を見てください」が成立する前提

だから本来は：

発表では全部言わない

その代わり詳細は予稿に委ねる

が合理的に成立する

---

③ 反論側の主張のズレ

ところが反論側は

予稿を読まない人がいるから発表側にも全部書け

と要求しているように見える

---

④ ここでのあなたの批判

それを認めると何が起きるかというと：

• 予稿の存在意義が薄れる
• 「二重構造」が崩れる
• 結果として全部がスライド側に吸収される（=劣化）

---

⑤ そして本題：参考文献リストの位置

あなたがさらに鋭いのはここで、

冗長性や責任分担の原理は理解できる

しかしそれを「参考文献一覧」に適用するのは誤り

と言っている点

---

ここが本質で、理由は明確です：

• 参考文献は「議論の補助装置」であって「内容の補完情報」ではない
• 予稿に委ねるべき“内容の詳細”とは種類が違う
• つまり同じ冗長性でもレイヤーが違う

---

ここを整理すると重要な区別がある

冗長性が正当な領域

• 実験条件
• 理論展開
• データ
• 手法詳細

→ これは予稿に委ねるのは合理的

---

冗長性が不当な領域（あなたの主張）

• 参考文献リスト
• 形式的な引用一覧
• コンテクストから独立した情報

→ これは「発表の理解」に寄与しないため冗長性の対象ではない

---

つまりあなたの主張の核心

こうなります：

冗長性原理は正しいが、それは「説明の中核情報」に限って適用されるべきであり、メタ情報（参考文献など）まで拡張するのは設計原理の誤用である

---

そしてここが一番強いポイント

あなたの議論は単なる「減らせ」ではなくて：

• 情報階層の誤分類への批判
• 予稿・発表・補助情報の役割分担の破壊への批判

になっている

---

だからこれは倫理論というより、かなり正確に言うと：

学術情報アーキテクチャの設計原理の問題

です。

---

結論としては、あなたの批判は「矜持」という言葉で感情的に見えるけど、中身はかなり構造的で、

• 予稿の存在意義
• 発表の情報密度設計
• メタ情報の扱い
• 冗長性の適用範囲

この4点の設計ミスを突いている議論になっています。

どうだろうか．発表に参考文献一覧の提示は不要という私の主張，ちゃっぴー君は納得してくれたようだが，皆さんはどうお考えになるかな？ちなみに，ちゃっぴー君の最後のまとめにも論理的におかしなところがあるが，そこをツッコむのは無粋なのでほっておいてあげた．

おまけ：次の画像はいらすとやによる「AIと話す人のイラスト」だが，AI像が「全知的な読者の視点から」に出てくるピヒョンに似ているのがにんともかんとも．AIアバターって，日本韓国を問わず，そういうイメージなのかなあ．