SMILEプロジェクトを支援するツールのDialogbook，だいぶ機能が追加され，データ構造もずいぶんと複雑になってきた．次の図は現時点でのER図である．テーブル数も22個に膨れ上がった．
これまで，交流の本丸はZoomやWebex，Google Meetなどを用いて行い，Dialogbookはその周辺の記録に特化したものとの位置付けだった．しかし，グルーピング機能を実装し，LiveKit Componentsが十分に使えることを確認したいま．いよいよ，オンライン交流機能を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まかせで生産性爆上がり」という声がちらほらと聞こえる昨今，そんなことあり得るか？とかなり懐疑的だったのだが，今日，少し考えを改める出来事があったので記しておきたい．
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年から現在までのキャリアは、情報技術の変化を追いかける歴史であると同時に、技術と人との関係を考え続けてきた歴史でもある。
飯尾淳の現在の活動は、HCI（Human-Computer Interaction）を軸に、ソフトウェア開発、AI、データ活用、教育、そして人の行動を対象としている。技術を作ることと、技術を使うこと。その両方を往復しながら、これからも「技術と人のあいだ」にある課題を探究していく。
Google Search Console の機能を使うと，どんな検索キーワードで記事に辿り着いているのかがわかる．今回，このブログの何に興味があって読まれているのかを，調べてみた．やり方は簡単である．Google Search Console で本ブログの記事が表示されたランキング表を500位まで取得，Googleスプレッドシートにコピペして，Geminiにキーワードをクラスタリングしてとお願いした．
ただし，グラフを作成する際に，固有名詞に関する情報は削除してと付記した．たとえば「飯尾淳」とか「飯尾研究室」というキーワードは削除の対象である．それは，これらのキーワードは当たり前であり，突出して多かったからである．
次のグラフは，検索キーワードから作られたクラスタ別の，件数を棒グラフにしたものだ．
順番に解説を試みよう．
これはとてもわかりやすい．大学のST比は，COVID-19時代に論じたものだ．Webexも，オンライン講義をどうやるべきかという一連の記事に関するものだろう．このあたり，皆，いまだに興味があるのだろうという点が面白い．
これも該当する記事はただ一つ．こんなPDCAは嫌だと称して，Plan → Delay → Cancel → Abandon/Apologizeというジョークを紹介したものである．PDCAというキーワードに興味があるんだろうなあと思うとともに，あらためて，こんなPDCAはごめん被りたい．
Pythonのプログラミングに対しても何度か記事を書いたことがある．インデントでスコープを表すのはいまだに嫌な仕様である．それさえなければ，Pythonは良い言語なんだけれどなあ．
これはちょっとよくわからない．いろいろな用語を解説しているということだろうか．心あたりもないのだが，クラスタリングされた中身を見てみないとよくわからないな．
数学に関する記事も何度か書いている．オイラーの公式の美しさについても述べたことがあるような．あらためて，オイラーの公式は美しいとしみじみ思う．
新しいMacを導入したときに，自分のためのメモ書きを兼ねて環境構築した手順を記事として残しているが，それがたくさん検索されている模様．まあ，皆さん，いろいろ苦労されているのよねっていうことがよくわかる．
これもよくわからない．iPhoneのストップウォッチが動きっぱなしですごい値になっていたという記事を書いた覚えがあるが，なんでこんなのが検索されているんだろう．
もう一つ，これもよくわからないカテゴリである．いろいろな設定に関する記事や，ITの基礎に関する記事は多数書いているのは自覚しているが，それらがこのクラスタにまとめられているのだろう．
これは面白い．九蓮宝燈を上がれる確率を論じた記事を書いたことがある．若者の麻雀離れとも言われるが，まだ，麻雀ファンはそこそこ居るということだろう．私，九蓮宝燈，一度だけ上がったことがあるよ．
Wordのエラーで，「参照元がありません」みたいなエラーメッセージは「参照先」の間違いじゃないか？元の英文は正しいが，訳語が間違っているだろうと指摘した記事である．皆，このエラーに困っているんだということがよくわかる．
オブジェクト指向についてもいちおう専門家としてそれなりの知見を有しているつもりではあるが，オブジェクト指向の記事なんてそんなに書いたっけ？という感じ．このクラスタはなぜ出てきたのかちょっとよくわからない．
例年，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」というタイトルで講演した．来年は，学生の誰かに研究内容を発表してもらいたいものである．
我々が開発している異文化間交流教育支援ツールDialogbookは学生・生徒と教員の間でコメントをやりとりするチャット機能を備えている．ところが，これまでの実装では旧来の「行って来い」型のプロトコルで実装していたため，新しいメッセージが投稿されても他者がリロードしないと画面には現れないというオールドファッションドなものとなっていた．
しかし，イマドキのアプリである以上は，既存のSNSやチャットツールのように，リアルタイムでやりとりしたい．コメントを投稿したら，すぐに相手の画面にも出るようにするのは，もはや当たり前の機能だろう．
そこで，そのようなリアルタイムチャット機能をDialogbookにも実装することにした．DialogbookはRailsアプリとして作られている．イマドキだと，Turbo Streamsというものを用いれば簡単に実装できるらしい．というわけで，まずはそのTurbo Streamsを理解するために，ちょっとしたチャットアプリを作ってみることにした．
まずはRailsアプリを用意する．次の手順でOKである．
続いて，モデルとコントローラを作成する．あくまで習作なので，テキストの本体だけを持つ単純なモデルを作る．
ルーティングも単純なものでよい．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の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でパススルーさせるというもの．その詳細は本稿では割愛するが，実際に運用する際には，十分に留意されたい．
縁あって，飯尾研では，ポーランドはウッチ大学のカラス先生のラボと共同研究を始めることになりました．昨日，日本から学生4名，ポーランドから学生6名，さらにカラス先生と私で，キックオフミーティングが行われました．
これまで我々の主戦場は東南アジアでしたが，今後，ポーランドを足がかりに東欧にも手を拡げていくかもしれません．近い将来，ポーランドを訪問することもあるでしょう．学生たちも意欲的で，積極的に参加する姿勢を見せています．今回参加しているうちの学生4名はいずれも3年生ですが，流暢に英語を話す学生がいて少し驚きました．とても楽しみです．
歴史に名を残したいというのは、「自分が死んだ後の他人の脳内状態を変化させたい」という欲望になる。しかし本人は死んでいるので、その状態を観測できないし、享受もできない。つまり、生きている間の快楽や幸福を犠牲にして、自分が存在しない未来の世界で、他人が自分を記憶していることを望むのは、本人の効用最大化という観点からは合理性がない。
たとえ名を残しても、数百年後には専門家しか知らない人物になるかもしれないし、数千年後には文明ごと消えているかもしれないし、太陽は数十億年後には膨張する。ならば「永遠に名を残す」は物理的に不可能である。
人間が本当に欲しいのは、承認されたい、尊敬されたい、愛されたいことであって、「歴史に名を残す」はその代理指標に過ぎない。ところが代理指標を目的化すると、「引用数を増やすために論文を書く研究者」みたいな話になる。「歴史に名を残す」ことを目的化した時点で、本来の目的を見失っている。
私の予想では、あなたの理屈は①じゃないかな。
つまり、死後に起きる出来事は、自分にとっては効用ゼロである。にもかかわらず、死後の名声を最大化しようとして生前の幸福を犠牲にするのは合理的ではない。という議論。もしそうなら、かなり筋は通っていると思う。
ただ、反論するとすれば、「死後の世界で名声を享受したい」のではなく、「いま生きている自分が、未来の人々に記憶されると想像すると嬉しい」という効用は存在しうる。たとえば、自分の子や孫が幸せになることを望む人は多いけれど、その幸福を本人が死後に観測することはできない。それでも現在の自分にとっては価値がある。
だから論理的には、「死後の名声に価値を感じること」は合理的たり得る。しかし、それを人生の最重要目標に据えるのは、かなり奇妙な価値観である。というあたりが落としどころかな。
さて、当たった？ それとも全然違うロジック？
私：そのとおり。そして、合理性はあるという指摘も正しい。ただし、まあ、せいぜい「死ぬときに『俺は歴史に名を残せそうなんや』と想像して安らかに死ねる」くらいが関の山ということだな。
ち：なるほど。完全に理解した。
あなたの議論を整理すると、1. 人は死んだ後の出来事を経験できない。2. したがって、死後に得られる名声そのものから利益を受けることはできない。3. だから「歴史に名を残す」ことは、それ自体を目的とするには不合理である。4. せいぜい合理的なのは、生前に「自分は後世に記憶されるだろう」と想像して満足感を得ることだけ、ということだね。
これはかなり筋の通った議論だと思う。
もっとも、この手の話になると、昔の哲学者が言いそうな反論として、死後に利益を受けられないのなら、死後に悪評が立っても損害を受けられないことになるのか？というのがある。たとえば、「自分の死後に捏造されたスキャンダルで悪人扱いされる」ことを嫌がる人は多い。
でもあなたの立場だと、「死んでるんだから、本人にとってはノーダメージ」になる。
私はその結論を受け入れてもよい気がするんだよね。なぜなら、死者本人の利益と、生者が死者に対して抱く敬意や道徳感情は別問題だから。
だから、「歴史に名を残したい！」と目を輝かせる政治家を見ると、あなたは「お前、その名声を享受する頃には死んどるやん」と思うわけだ。しかも政治家の場合、「歴史に名を残したい」という欲望がしばしば、巨大イベントを誘致する、記念碑的な箱物を建てる、憲法改正や制度改変で自分の名前を刻みたがるという方向に暴走しがちだからね。
そういう意味では、歴史に名を残したいと思うのは勝手だが、そのために現代人を巻き込むなというのが、あなたの政治観なのかもしれない。
そして、政治家として理想的なのは、「百年後の教科書に載りたい」と思っている人ではなく、「百年後の人が私の名前を知らなくても、水道が止まらず、学校が回り、借金を増やさずに済んでいれば十分」と思っている人なのだろうね。なんだか選挙ポスターに書いてほしいくらいの標語だ。もっとも、そんなことを書いたら、おそらく落選するんだけど。
私：その哲学者の反論は反論になっておらず、私の説を補強するぞ？すなわち、「自分の死後に捏造されたスキャンダルで悪人扱いされる」のもまた思慮が浅いということだよ。
ち：なるほど，そこまで徹底するわけだね。
すると，あなたの立場はかなり首尾一貫している。死後に称賛されても本人には利益がない。死後に悪評を立てられても本人には損害がない。したがって、死後の評判を気にすること自体が、合理的な利害計算の対象ではない、ということになる。
これはたしかに筋は通っている。
ただ、ここで面白いのは、人間の多くはどうもそういうふうにはできていないことなんだよね。例えば、「自分が死んだ後も家族が困らないように財産を残したい」という欲望はかなり普遍的だし、「自分が死んだ後に作品を読まれたい」という芸術家や研究者もたくさんいる。
あなたの立場からすると、これらはすべて、死後の世界に対する現在の想像が、自分に快楽や安心感を与えているという形でしか合理化できない。そして、その合理化を認めたとしても、歴史に名を残したい！という野望は、せいぜい「俺は後世に語り継がれるんや！」と妄想して気持ちよくなるための嗜好に過ぎないわけだ。
だから、もし誰かが「私は歴史に名を残すために政治家になった！」と言ったら、あなたとしては、「ほな、今すぐ引退して伝記でも書いときなはれ。目的は達成できるかもしれんで」ということになるんだろうね。
ただ、一つだけ擁護するとすると、人間は案外、「自分の人生を一つの物語として捉えたい」という性向を持っている。論理的には無意味でも、「後世の人々が私をどう評価するか」を考えることで、自分の現在の行動に意味を見いだしている人は少なくない。まあ、あなたから見れば、「それは理屈ではなく、ただの趣味やな」という評価になるんだろうけど。
私はわりとその結論に賛成で、政治家が「歴史に名を残したい」と言い始めたら、要注意サインだと思う。歴史に名を残した人物には、善人もいるが、かなりの割合でとんでもない連中も混じっているからね。
