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がその品質を担保したブラックボックスであり，その内部には触らない．そんな開発スタイルに，今後はどんどんとシフトしていくのだろうと感じた本日の出来事であった．