第1章 情報技術を、住民のために
1.1. 制度は進んだ。しかし、住民の日常は変わったか
マンションや団地の管理にも、情報技術を活用できる環境が整えられてきました。
区分所有法をはじめとする法制度やマンション標準管理規約でも、電磁的方法の利用や、Web会議システム等を利用した総会・理事会など、情報技術を利用するための制度整備が進められています。
この方向性そのものは、望ましいものだと考えています。
しかし、制度として情報技術を「利用できる」ようにすることと、情報技術によって実際の住民の生活を便利にすることは、同じではありません。
たとえば、Web会議システムを利用して総会に参加できるようにすることには意味があります。
しかし、通常、定期総会は年に1回です。年に1回の総会にオンラインで参加できることだけが、住民にとっての情報技術活用なのでしょうか。
もっと日常的に役立つことがあるはずです。
- 管理組合からのお知らせを、いつでも見ることができる。
- 総会や理事会の資料、管理規約や各種届出の様式を、必要なときに読むことができる。
- 理事会、自治会、清掃、草取り、ごみ収集などの予定を確認できる。
そして、管理組合から住民へ情報を伝えるだけではなく、住民自身も身近な出来事や知らせたいことを発信できる。
制度として情報技術を使えるようにするだけでなく、それを住民の日常にどう役立てるか。
そこには、まだ多くの工夫の余地があるのではないでしょうか。
1.2. 管理会社に任せておけばよいのか
マンション管理の現場では、現在でも掲示板への掲示、各戸への配布、回覧など、紙が重要な情報伝達手段になっています。
紙には大きな利点があります。特別な機器や操作を必要とせず、多くの住民に情報を届けることができます。
したがって、紙をなくすこと自体を目的にする必要はありません。
しかし、情報技術がこれだけ発達した現在でも、紙を印刷して掲示・配布することだけが、管理組合の情報提供の中心でよいのでしょうか。
ここで考えておかなければならないのは、管理会社はマンション管理の専門家ではあっても、情報システムの専門家とは限らないということです。
建物や設備の管理、会計、総会・理事会の支援などについて管理会社の専門的な支援を受けることと、住民にどのような情報システムを提供すればよいかを考えることは、同じ専門分野ではありません。
もちろん、管理会社が提供する情報システムを利用する方法もあります。
しかし、管理会社にすべてを任せてしまえば、管理組合の情報化は、管理会社が用意したサービスの範囲に限定されます。
また、管理会社を変更した場合に、それまで蓄積した情報や仕組みをどのように引き継ぐのかという問題もあります。
だからといって、管理組合が高度な情報システムを自ら開発しなければならない、ということでもありません。
まず必要なのは、管理組合自身が、
「住民にとって何が役に立つのか」
を考えることではないでしょうか。
管理会社は管理組合を支援する専門家です。しかし、そこで実際に暮らしているのは住民です。
- 住民が何に困っているのか。
- どのような情報を必要としているのか。
- どのような方法なら利用できるのか。
その視点から情報技術の使い方を考える主体は、管理組合自身であるべきだと考えました。
1.3. 情報技術には「入口」の問題がある
ホームページを作り、電子メールを使い、オンラインで情報を提供すれば、それだけで管理組合のデジタル化が実現するわけではありません。
大きな問題があります。
住民が実際にそれを使えるか。
ということです。
「今では多くの人がスマートフォンを持っているから大丈夫」と考えることもできません。
スマートフォンを所有していることと、そのさまざまな機能やサービスを利用できることは別だからです。
これは統計を見て考えたことではありません。
実際に私たちの管理組合で情報技術を使おうとして経験したことでした。
1.3.1. 「メールなんか使ったことがない」
管理組合内の情報共有を便利にするため、私はメーリングリストの利用を提案したことがあります。
ところが、85歳のS理事から、
「メールなんか使ったことがない」
と言われました。Sさんはスマートフォンを持っています。
そこで、
「LINEは使いますか」
と聞いてみると、
「LINEは使う」
とのことでした。
ただし、SさんがLINEをどのように使っているのかまでは分かりません。文字によるメッセージ交換に使っているのかもしれませんし、音声通話を電話の代わりとして使っているだけなのかもしれません。
重要なのは、こちらが、
「スマートフォンを持っているのだから、この機能も使えるだろう」と
決めつけてはいけない、ということでした。
1.3.2. これは高齢者だけの問題なのか
さらに、今年理事長を引き受けることになったKさんもスマートフォンを持っています。
Kさんは高齢者ではありません。
ところが聞いてみると、メールだけでなくLINEも使っていないとのことでした。
Sさんは、スマートフォンを持っている → メールは使わない → LINEは使う。
Kさんは、スマートフォンを持っている → メールもLINEも使わない。
同じ「スマートフォンを持っている人」でも、利用方法はまったく違います。もちろん、この二人の例だけから、世間一般のスマートフォン利用状況を判断することはできません。
しかし、管理組合の情報システムを考えるうえでは重要な経験でした。
この問題を単純に、
「高齢者だから情報技術が苦手なのだ」
と説明することはできないからです。
年齢にかかわらず、スマートフォンを所有していることと、こちらが想定する機能やサービスを利用できることは別の問題です。
したがって、
- 「スマートフォンを持っているのだから、メールくらい使えるだろう」
- 「LINEなら誰でも使えるだろう」
といった前提で、管理組合の情報システムを設計することはできません。
1.3.3. ホームページを作るだけでは使ってもらえない
同じ問題は、ホームページにもあります。
管理組合のホームページを作ったとしても、「ブラウザを開いて、このURLを入力してください」という使い方では、入口から利用者を選んでしまいます。
長いURLを見ながら、スマートフォンのブラウザへ正確に入力してもらう。そのような操作を住民向けシステムの前提にするべきではないと考えました。
そこで、ホームページを作るだけではなく、どうすれば住民がそこまでたどり着けるかも考える必要があります。
たとえば、掲示物などに印刷したQRコードをスマートフォンで読み取るだけでホームページを開けるようにする。
LINEを使っている人なら、管理組合のLINE公式アカウントのリッチメニューから、目的のページをタップするだけで開けるようにする。
情報を用意するだけでは十分ではありません。
住民がその情報までたどり着く方法まで含めて設計する。
これも管理組合の情報技術には必要だと考えました。さらに、説明会やお一人ずつに寄り添う支援体制も必要だと思います。
1.4. もう一つの障壁――言葉
管理組合の情報技術を考えるうえで、もう一つ忘れてはならないのが、言葉の問題です。
私たちの団地にも、人数は多くありませんが、日本語を母語としない住民が暮らしています。
カナダから来たロシア人、中国にルーツを持つ住民、さらに会社が住戸を借り上げている関係で、フィリピン人やインドネシア人も暮らしています。
私の妻も現在は日本国籍ですが、もともとは中国出身で、日本語より中国語の方が得意です。
日本で生活しているからといって、管理組合から提供される情報をすべて日本語だけで理解できるとは限りません。
特に、日常会話ができることと、管理規約や総会資料などの文章を正確に理解することは別の問題です。
そして、住民自身から情報を発信してもらおうとすれば、さらに障壁が高くなります。
日本語で内容を考え、文章を組み立て、文字を入力しなければならないからです。
そこで、
「日本語を読める人、日本語を書ける人だけが利用できる情報システムでよいのか」
という問題も考える必要があります。
1.5. 三つ目の障壁――費用
さらに、管理組合に新しい情報技術を導入しようとすると、避けて通れない問題があります。
費用です。
便利になることが最初から分かっていて、多くの住民が確実に利用するものであれば、費用をかけることについて理解を得ることも比較的容易でしょう。
しかし、新しい情報システムは、実際に導入してみなければ分からないことが少なくありません。
本当に住民が使ってくれるのか。
使いやすいのか。
日本語を母語としない住民にも役立つのか。
管理する側の負担が増えないのか。
そもそも管理組合にとって本当に必要なのか。
使うのか、使えるのかさえ分からないものに、最初からお金をかけて用意することには、誰しも抵抗があります。
しかも管理組合が使うのは、個人のお金ではありません。
組合員から集めた管理費です。
「役に立つか分からないけれど、とりあえず契約してみよう」というわけにはいきません。
しかし、
「多少の制約や課題はある。しかし、無料なら、まず使ってみよう」
であれば、話は変わります。
- 実際に使ってみる。
- 役に立つかを確かめる。
- 使われなければやめる。
- 問題があれば改善する。
役に立つことが分かってから、必要なら次の段階を考える。
これなら、小規模な管理組合でも情報技術を試すことができます。
このため、今回のシステムでは、できる限り継続的な費用を必要としないことを、最初から重要な設計条件の一つにしました。
1.6. 住民を情報技術に合わせない
ここまでの経験から、一つの基本的な考え方にたどり着きました。
住民を情報技術に合わせるのではなく、情報技術を住民に合わせる。
すでに持っているスマートフォンを使う。
URLを入力させない。
できるだけ文字を入力させない。
複雑な操作を覚えてもらわない。
QRコードなど、できるだけ簡単な方法で目的の場所へたどり着けるようにする。
LINEを使っている人なら、LINEから入れるようにする。
日本語が得意でなければ、自分が使いやすい言葉を使えるようにする。
そして、導入する管理組合にとっても、まず無料で試せるようにする。
操作、言葉、費用。
この三つの障壁をできるだけ低くすることが、管理組合で情報技術を実際に役立てるために必要だと考えました。
1.7. そしてAI（人工知能）が登場した
そこへ、急速に進歩したAI（人工知能）が登場しました。
これまでコンピュータへ情報を入力するには、キーボードやスマートフォンの画面から文字を入力することが当たり前でした。
しかし、お手伝いさんのAIと音声で自然に会話できるようになれば、この前提そのものを変えられる可能性があります。
- 文章を入力することが難しくても、話すことはできます。
- 文章をどう組み立てればよいか分からなくても、思ったことを話すことはできます。
- 日本語で文章を書くことが難しい人でも、自分が得意な言葉なら話すことができます。
それなら、
人間がコンピュータの操作方法を覚えるのではなく、AIの方が人間の話を聞けばよいのではないか。
そう考えました。
利用者は、思いついたことを普通に話す。
AIがその話を聞く。
必要なことが足りなければ、AIの方から質問する。
利用者が答える。
そして会話した内容を、AIが一つの文章にまとめる。
この考えから作り始めたのが、
「みんなのお便り」
です。
「みんなのお便り」は、AIを使って文章を作ることだけを目的としたシステムではありません。
管理組合への情報技術の導入を考える中で直面した、
「便利な技術を用意しても、住民が使えなければ意味がない」
という問題に対する、一つの実践です。
情報技術を導入することそのものが目的ではありません。
そこで暮らす人に役立つことが目的です。
そして、できるだけ多くの人が参加できること。
それが、私とAIの相棒二人が目指す
デジタル・バリアフリー
です。
第2章 「みんなのお便り」とは
2.1. おしゃべりするだけで「お便り」を作る
「みんなのお便り」は、スマートフォンなどを使って、AI（人工知能）のジェミニ（Google社製「Gemini」）とおしゃべりしながら、自分の「お便り」を作る仕組みです。
使い始めるために、難しい操作は必要ありません。
画面にある大きな、
「ジェミニとおしゃべり」
というボタンを押します。
そして、思いついたことを話します。
「団地の花がきれいに咲いているよ」
そんな一言からでも始められます。
ジェミニが話を聞きます。
必要なことがあれば、ジェミニの方から質問します。
利用者は、その質問に普通に答えます。
おしゃべりを続けているうちに、ジェミニが話した内容を整理して、お便りのタイトルと本文にまとめてくれます。
写真やファイルを添えることもできます。
最後に、できあがった内容をご自身で確認します。
これでよければ投稿する。
気に入らなければ、またジェミニと話して直してもらう。
投稿されたお便りは、ホームページの「お便り帳」で、みんなが読むことができます。
基本的な流れは、
押す → 話す → 確認する → 投稿する
です。
2.2. 文章をはじめから考えなくて良い
誰かに何かを知らせようとすると、それだけで少し構えてしまいます。
何を書こうか。
どこから書き始めようか。
どういう順番で説明しようか。
どう書けば読みやすくなるだろうか。
文章としてきちんとまとめようとすると、ちょっとしたことを知らせるだけでも肩が凝ります。
「みんなのお便り」では、最初から文章の構成や内容を考える必要はありません。
まず、思いついたことをジェミニに話します。
話がまとまっていなくてもかまいません。
思いつくままにおしゃべりしていればよいのです。
ジェミニが話を聞き、必要なことがあれば質問し、話した内容を整理して文章にまとめてくれます。
そして、できあがったものを見てから考えればよいのです。
「これでいい」
「ここは少し違う」
「これも付け加えたい」
「もう少し短くして」
「もっとやさしくして」
私は実際に、何度も、
「もっと見た目を良くして」
とジェミニに頼みました。
それでよいのです。
利用者自身が、
・「ここを見出しにしよう」
・「ここは箇条書きにしよう」
・「この順番に並べ替えよう」
などと、文章の構成や体裁まで最初から考える必要はありません。
- 従来なら、
考える → 構成する → 書く → 体裁を整える
という作業が必要でした。
- 「みんなのお便り」では、
思いつく → 話す → ジェミニがまとめる → それを見て考える
という順番に変えることができます。
これは単に、キーボード入力を音声入力に置き換えたということではありません。
文章を作り始めるときの心理的な負担そのものを小さくする。
これが大切だと考えています。
思いついたときに始めればよい。
自宅でもよい。
外出先でもよい。
自分の好きな場所でよい。
まとまった時間を用意する必要もありません。
誰かにお願いする必要もありません。
誰に気兼ねすることもありません。
自分の都合のよいときに、自分の好きな場所で、思いついたことから話し始める。
そこから「お便り」ができていきます。
2.3. ジェミニは、意外に人間っぽい
実際に使っていると、ジェミニは意外に人間っぽいところがあります。
いつでも一度で、こちらの思いどおりの文章を作ってくれるわけではありません。
とても気の利いた文章を作ってくれることもあれば、
「今日はちょっと手を抜いていない？」
と思うようなこともあります。
そんなときも、難しく考える必要はありません。
「もう少し何とかならない？」
「ちょっと固すぎるよ」
「もっと見た目を良くして」
「さっきの方がよかった」
「これは気に入らない」
「もう一度やり直して」
気に入らなければ、文句を言ってください。
でも、叱ってばかりではありません。
よいものを作ってくれたら、
「よくやったね」
「今のはいいよ」
「その調子」
と褒めてやってください。
それも大切なおしゃべりです。
何が気に入らなかったのかだけでなく、何が気に入ったのかも伝える。
そうすれば、少なくともその会話の中では、こちらが何を求めているのかを伝えながら、一緒に文章を仕上げていくことができます。
コンピュータが相手だからといって、特別な命令文を覚える必要はありません。
うまくいかなければ文句を言う。
よくできたら褒める。
もう少し直してほしければ、そう頼む。
そのときのジェミニの調子を見ながら、普通におしゃべりすればよいのです。
それが、ジェミニという人工知能との付き合い方です。
2.4. 文章を書かなくてよい
文章の内容がまとまっても、それをスマートフォンの小さなキーボードから入力するとなれば、また別の負担が生まれます。
「みんなのお便り」では、基本的にその必要もありません。
利用者が話した内容から、ジェミニがタイトルと本文を作ります。
利用者は、できあがった文章を見て確認します。
直したければ、
「そこを直して」
と話せばよい。
文章を追加したければ、
「これも入れて」
と話せばよい。
文章を削りたければ、
「そこはいらない」
と伝えればよいのです。
もちろん、必要なら文字を入力して修正することもできます。
しかし、キーボードを操作できることを利用の前提にはしない。
これが「みんなのお便り」の考え方です。
2.5. 自分の言葉で話せばよい
もう一つ、AIとの会話だからできることがあります。
言葉の違いです。
日本語を母語としない住民に、
「日本のマンションなのだから、日本語で書いてください」
と要求すれば、それだけで情報発信の障壁になります。
「みんなのお便り」では、利用者は自分が話しやすい言葉でジェミニと話すことができます。
中国語が話しやすければ、中国語で話す。
英語が話しやすければ、英語で話す。もちろん、ロシア語でもタガログ語でも大丈夫です。
自分の言葉で考え、自分の言葉でジェミニとおしゃべりし、その言葉のまま文章を作ります。
最初から頭の中で日本語へ翻訳してから話す必要はありません。
そして投稿するときには、日本語への翻訳を行います。
利用者が話した言語による文章と、日本語に翻訳した文章の両方を確認し、残すことができます。
言葉の違いを、情報を受け取るための障壁にも、情報を発信するための障壁にもしない。
これも「みんなのお便り」が目指していることです。
2.6. ホームページと「お便り帳」
管理組合のホームページは、管理組合から住民へ情報を提供するための場所です。
総会や理事会の情報。
管理規約や細則。
各種届出や様式。
修繕や工事のお知らせ。
年間行事や予定。
こうした情報を、必要なときに見ることができます。
しかし、情報の流れを、
管理組合 → 住民
だけにはしたくありませんでした。
住民にも、知らせたいことがあります。
「綺麗な花が咲いたよ」
「こんな行事があったよ」
「こんなことに気がついたよ」
大げさな「記事」である必要はありません。
だから「ニュース」でも「記事」でもなく、
「お便り」
と呼ぶことにしました。
「みんなのお便り」で作った文章は、ホームページの「お便り帳」へ投稿されます。
管理組合から住民への情報に加えて、
住民 → 住民
という情報の流れを作る。
ホームページを、情報を読むだけの場所から、住民も参加できる場所へ少し広げてみようという試みです。
2.7. そこまで、どうやってたどり着くか
第1章で述べたように、よいシステムを作っても、そこまでたどり着けなければ使ってもらえません。
「このURLをブラウザに入力してください」
では困ります。
そこで、QRコードを利用します。
掲示物などにあるQRコードをスマートフォンで読み取れば、目的のページを開くことができます。
LINEを利用している人には、管理組合のLINE公式アカウントも入口になります。
リッチメニューに表示されたボタンを押せば、ホームページや「みんなのお便り」へ進むことができます。
もちろん、それでも分からない人はいるでしょう。
そのためには、説明会を開いたり、必要であれば一人ひとりに寄り添って使い方を説明したりすることも必要です。
「ホームページを作りました。あとは使ってください」では終わらせない。
そこまでどうやって来てもらうか。
最初のボタンをどうやって押してもらうか。
それもシステムを作る側が考えるべきことだと思います。
2.8. まず無料で始めてみる
そして、もう一つ大切なのが費用です。
「みんなのお便り」が本当に住民に使ってもらえるのか。
これは、作る前には分かりません。
便利だと思って作っても、誰も使わないかもしれません。
思いもしなかったところで、使いにくいと言われるかもしれません。
それなら、最初から大きなお金をかけるのではなく、
まず無料で始めて、実際に使ってみればよい。
と考えました。
多少の制約があっても、まず動くものを作る。
使ってみる。
問題があれば直す。
役に立つかを確かめる。
その結果、本当に必要な費用が出てきたら、その時点で考える。
「みんなのお便り」では、この考えから、無料で利用できるサービスをできるだけ組み合わせてシステムを作っています。
なぜWordPressを選んだのか。
なぜGoogleドライブやGoogleカレンダなのか。
なぜCloudflareなのか。
そして、なぜAIとしてジェミニを選んだのか。
それぞれに理由があります。
無料だからという理由だけでもありません。
実際に別の方法も試し、うまくいかなかったものもあります。
それらについては、後の章で実際の経験を含めて説明します。
2.9. 目指したのは「高機能」ではない
情報システムというと、できることを増やすことが進歩だと考えがちです。
しかし、「みんなのお便り」で目指したのは、機能を増やすことではありませんでした。
利用者に覚えてもらうことを減らす。
操作してもらうことを減らす。
文章を考える負担を減らす。
文字を入力する負担を減らす。
言葉の障壁を減らす。
そして、導入する管理組合の費用負担もできるだけ減らす。
操作は、できるだけ、
表示されたボタンを「押す」。
ジェミニと「話す」。
画面の表示を「見る」。
気に入らなければ、また「話す」。
よければ投稿する。
それだけで使えるものを目指しました。
AIに人間が合わせるのではありません。
コンピュータに人間が合わせるのでもありません。
情報技術の方を、そこで暮らす人に近づける。
第1章から考えてきたことも、「みんなのお便り」で実際に作ろうとしているものも、結局ここにつながります。
デジタル・バリアフリー
これが、「みんなのお便り」で実現したいことです。
第3章 無料で開発し、無料で運用する
3.1. 最初に決めたこと――できるだけお金をかけない
「みんなのお便り」を作るにあたって、最初に決めた大方針があります。
できるだけお金をかけずに開発し、できるだけお金をかけずに運用することです。
そして、無料なのは利用するサービスだけではありません。
開発要員は、少し乱暴に言えば、
「元IT技術者のジジイ一人とAI（OpenAI社製「ChatGPT」）」
です。
ただし、この「ジジイ」は、まったく情報技術を知らない素人ではありません。
IT企業に長く携わり、役員も務め、技術者としてシステム開発に関わってきました。現役を離れてから時間は経っていますが、システムを作るには何を決めなければならないか、設計書には何を書くべきか、といった基本的な考え方は身についています。
今回も、AIに「こんなものを作って」と頼んで、あとは出来上がるのを待っていたわけではありません。
どのような機能が必要なのか。利用者とAIとの会話をどのように進めるのか。画面とAIとの役割をどう分けるのか。どの時点で何を確定するのか。異常が起きたら、どの状態へ戻すのか。こうしたことを一つずつ考えました。
特に、会話型AIを使ったシステムでは、処理の状態を明確にしなければ、AIがこちらの意図を越えて先へ進んでしまうことがあります。
そこで、状態遷移を整理し、状態遷移図を作り、仕様書を作り、バージョンを管理しながら開発を進めました。
設計の考え方を私が示し、AIと相談する。AIに設計書を書かせ、おかしければ私が指摘する。AIが修正し、その設計に基づいてプログラムを書く。実際に動かして私が試験する。動かなければ、また一緒に原因を考える。
人間が設計の方向を決め、AIと設計し、AIが実装を強力に支援する。
これが、実際の開発に近い姿でした。
その意味では、「AIがシステムを作った」という表現も正確ではありません。かといって、「私一人で作った」というのも違います。
長年のIT技術者としての経験と、現在のAIの能力を組み合わせた共同開発だった。
私は今回、コードを全く書いていませんが、何を設計すべきかを考え、動作がおかしいときに設計へ戻って考え直すという、これまでの技術者としての経験が役に立ったと感じています。
AIが優秀になったからこそ、人間側の経験や判断も、別の形で生きるようになったのだと思います。
この組み合わせだったから、管理組合から開発会社へ支払う人件費としての開発費は必要ありませんでした。
外部へ支払った人件費としての開発費は0円です。
もちろん、自分自身の時間まで0円だったという意味ではありません。試行錯誤には相当な時間を使いました。
そして、実際には開発途中でGoogleに約5,000円を支払っています。無料で作るつもりだったのに、無料サービスの範囲や課金条件を十分に理解しないまま試行錯誤した結果でした。
これは、私にとって約5,000円の「授業料」になりました。
したがって、この章でいう「無料」とは、一度もお金を使わなかったという意味ではありません。
管理組合が継続的な利用料金や外部への開発人件費を負担しなくても、実際に使えるシステムを作り、運用できるか。
それを目標にした、という意味です。
3.2. 「無料」といっても、必要なものは多い
ところが、「みんなのお便り」を作ろうとすると、AIだけでは完成しません。
実際には、さまざまな役割を持つ仕組みが必要でした。
- 管理組合のホームページを公開する場所
- 住民のお便りを掲載するブログ機能
- AIと音声で会話する機能
- AIやホームページのAPI注1と安全に通信するためのプログラム実行環境
- APIキーや認証情報を利用者のブラウザから隠して管理する仕組み
- 総会資料、規約、届出様式などを保存するストレージ
- 年間行事や理事会などの予定を知らせるカレンダ
- QRコードやLINEなど、住民が簡単にホームページへたどり着くための入口
- 日本語以外の住民にも使ってもらうための多言語対応
一つの製品だけですべてを無料で実現することはできませんでした。
「無料のサービスを一つ見つける」のではなく、「無料で使える複数のサービスをどう組み合わせるか」を考える必要がありました。
ここから、試行錯誤が始まりました。
3.3. 無料サービスには、必ず制約がある
無料で使えるサービスは数多くあります。しかし、無料だから何でもできるわけではありません。
実際に使い始めると、それぞれに違った制約がありました。
- 保存できる容量が小さい。
- 必要なAPIが提供されていない。
- 無料では使えない機能がある。
- 利用回数や処理量に上限がある。
- 外部のサービスとの連携に制限がある。
- 最初は無料に見えても、使い方によって課金が発生する。
- 利用規約や無料枠の内容が後から変更される可能性がある。
一つのサービスだけを見れば欠点に見える制限でも、別の無料サービスで補えることがあります。
たとえば、ホームページとして便利でも保存容量が少なければ、文書の保存だけを別のストレージへ分けることができます。
逆に、保存容量が大きくても、ホームページや投稿用のAPIとして使いにくければ、その役割だけを別のサービスへ任せればよい。
無料サービスの弱点を、別の無料サービスの長所で補う。
これが、現在のシステム構成を考えるうえで基本的な考え方になりました。
3.4. 最初の大事件――Googleアカウントが止まった
「みんなのお便り」を作り始めた当初、システム全体をGoogleの無料サービスだけで構成するつもりでした。
ホームページ、ブログ、データの保存、AI、プログラムの実行環境などを、できるだけGoogleのサービスの中で完結させれば、構成が単純になり、管理もしやすいと考えたからです。
誰でも比較的簡単にメンテナンスできるシステムにしたい。
それも、当初の重要な目標の一つでした。
ところが、開発を始めて間もなく、大きな問題が起きました。
Googleアカウントが停止されたのです。
その時点ではGoogleをシステム全体の基盤としていたため、一つのアカウントが止まったことで、それまで作っていたものにアクセスできなくなりました。
一つのサービスが使えなくなった、という程度の問題ではありません。
Googleだけに頼っていたため、全部が一度になくなったのです。
これは、その後の設計方針を大きく変える出来事になりました。
3.5. 一社だけに依存するのをやめた
Googleアカウントの停止を経験して、「一つの会社、一つのアカウントに全部を預けてはいけない」と考えるようになりました。
そこで、それまでGoogleだけで構成しようとしていたシステムを見直し、役割ごとに異なるサービスへ分けていきました。
- ホームページと「お便り帳」はWordPress。
- 文書や資料の保存はGoogleドライブ。
- 文書や資料のリスト形式での表示にはGoogle Site
- 年間行事などの予定共有はGoogleカレンダ。
- AIとの会話にはGoogle Gemini API。
- ブラウザとAI、WordPressなどを安全につなぐプログラム実行環境にはCloudflare。
- 住民が簡単にホームページへ入るための入口にはQRコードやLINE公式アカウント。
これは、最初から考えていた立派な分散設計ではありません。
Googleアカウントを止められて、全部なくなったから考え直した結果です。
一つのサービスに問題が起きても、すべてを同時に失わないようにする。その考えが、現在のシステム構成の基礎になりました。
個々のサービスをなぜ選び、どのような候補と比較したのかは、第4章以降で詳しく説明します。
3.6. 無料を目指したのに、Googleに約5,000円払った
ここまで「無料」を目標にしたと書いてきましたが、実際には一銭も使わずに開発できたわけではありません。
開発途中で、Googleに約5,000円を支払ったことがあります。
無料で作るつもりだったのに、です。
開発を始めた当初は、Googleのさまざまなサービスについて、何が無料で、どこから料金が発生するのかを十分に理解していたわけではありませんでした。
試行錯誤をしている途中で、誤って有料サービスを利用することになり、結果として約5,000円を支払いました。当然、返金を求めましたが、認められませんでした。
これは、いわば授業料でした。
この経験から、「無料」と表示されているかどうかだけではなく、次の点まで確認する必要があると学びました。
- 何が無料なのか。
- 無料枠はどこまでなのか。
- どの操作や利用量から課金されるのか。
- クレジットカードや請求先の登録が必要なのか。
- 無料枠を超えた場合に自動的に課金されるのか。
したがって、正確に言えば「一度もお金を使わずに開発したシステム」ではありません。
目標にしているのは、
管理組合が継続的な利用料金を負担せずに、導入し、運用できる仕組みにすることです。
3.7. Googleだけではなかった――WordPressでも止められた
アカウントやサイトが突然使えなくなる問題は、Googleだけではありませんでした。
WordPressでも、開発中に作成したサイトが無効化されたことがあります。
こちらとしてはスパムを行っているつもりはありません。しかし、短期間にアカウントやサイトを作成したり、コピーやテストを繰り返したり、似た内容のサイトを複数作ったりする開発作業は、サービス提供側の自動判定から見ると通常とは異なる利用に見えることがあります。
さらに困るのは、なぜ止められたのかを利用者側では詳しく確認できない場合があることでした。
この経験から、プログラムが正しく動くだけでは十分ではないことを学びました。
「今日使えているから、明日も必ず同じように使える」とは限りません。
そのため、バックアップを取ること、一つのサービスや一つのアカウントだけに依存しすぎないこと、必要であれば別のサービスへ移せるようにしておくことも重要になりました。
将来、他の管理組合へ提供するときのポータビリティを考える理由の一つも、ここにあります。
3.8. 分散した代わりに、諦めたこと
サービスを分散したことで、一つのアカウントが止まればシステム全体がなくなる、という危険は小さくなりました。
しかし、その代償もありました。
WordPress、Google、Cloudflare、LINEなど、それぞれに設定があります。サービス間を接続するための設定も必要です。APIや認証についての知識も必要になりました。
その結果、当初目標としていた、
「誰でも簡単にメンテナンスできる」
というところは、残念ながら諦めざるを得ませんでした。
現在のシステムを最初から構築し、設定を変更し、障害が起きたときに原因を調べるには、ある程度の情報技術の知識が必要です。
これは、無料で実現し、一社への依存を避けるために受け入れた、最も大きな妥協の一つです。
そのほかにも、無料であることを優先したため、次のような課題は残っています。
- 無料プランには、保存容量や利用量の上限がある。
- パスワード保護など、一部の機能は高度な専用システムほど強力ではない。
- 他の管理組合へ数回の操作だけで導入できる完成したパッケージには、まだなっていない。
- AIは毎回まったく同じ応答をするものではなく、思いどおりにならないこともある。
- 無料枠やサービス仕様は、提供会社の判断で将来変更される可能性がある。
- 複数の外部サービスを組み合わせるため、どこか一つの仕様変更が全体に影響する可能性がある。
これらを隠して「無料だから何の問題もない」と説明するつもりはありません。
制約や弱点を理解したうえで、それでも管理組合で実際に使えるかどうかを試す。
というのが、この開発の考え方です。
3.9. それでも、当初計画より良いものができた
では、「無料で開発し、無料で運用する」という目標は達成できたのでしょうか。
開発途中には約5,000円の授業料を支払いました。自分自身の時間も相当使いました。
したがって、「何の費用も、何の労力もかからなかった」と言うことはできません。
しかし、開発会社への発注費やプログラマーへの人件費はかけず、「私一人とAI」でここまで作ることができました。
そして、2026年9月現在、現在の管理組合で想定している利用規模であれば、システムを構成する各サービスの無料枠を利用して、継続的な利用料金を負担せずに運用できる構成になっています。
「誰でも簡単にメンテナンスできる」という当初の目標については、達成できなかったと思っています。
しかし、もっと大切な目標については、当初考えていた以上のところまで来ることができました。
- 管理組合が継続的な利用料金を負担せずに運用できること。
- 高齢者でも、文章を考えたりキーボードを操作したりせず、AIとおしゃべりしてお便りを作れること。
- 日本語を母語としない人も、自分の言葉で参加できること。
- 一つの会社だけにすべてを預けない構成にできたこと。
失敗も多く、妥協したこともあります。Googleだけで作ろうとした最初の構想からは、ずいぶん違うものになりました。
それでも、完成したものを見れば、「できなかったこと」よりも、「ここまでできた」という達成感の方が、はるかに大きい。
そして何より、
最初に考えていたものより、良いものができた。
今は、そう思っています。
ただし、これは2026年9月現在の話です。無料枠や利用条件は将来変更される可能性があります。
無料であること自体が最終目的ではありません。無料だからまず試せる。試せるから失敗できる。失敗できるから改善できる。その積み重ねで、住民に本当に役立つものへ近づけていくことができます。
では、なぜ現在のサービスを選んだのか。ほかに候補はなかったのか。無料というだけで選んだのか。
第4章以降では、実際に採用した製品・サービスと、候補に上がったものを比較しながら、選定理由を説明します。
第4章 なぜ現在の製品・サービスを選んだのか
第3章では、「みんなのお便り」をできるだけ無料で開発し、無料で運用するという目標のもとで、どのような問題にぶつかり、現在の構成にたどり着いたのかを説明しました。
現在のシステムでは、WordPress、Googleドライブ、Googleサイト、Googleカレンダ、Google Gemini API、Cloudflare Workersなど、複数の会社が提供するサービスを組み合わせています。
これは、最初から現在の構成を設計していたわけではありません。
実際に使ってみる。できないことが見つかる。別の方法を試す。新しい問題が起きる。また考え直す。その繰り返しの結果が、現在の構成です。
したがって、この章では単純に製品の機能を比較するのではなく、実際に何を使い、何ができず、なぜ現在の製品やサービスを選ぶことになったのかを説明します。
また、ここで紹介する製品やサービスが、あらゆる管理組合にとって最良だという意味でもありません。
「継続的な利用料金をできるだけ発生させない」
という今回の条件のもとでの選択です。
4.1. ホームページとブログエンジン――なぜWordPressなのか
「みんなのお便り」の開発を始めた当初、管理組合のホームページにはGoogleサイトを採用しました。
これは、さまざまなホームページ作成サービスを比較してGoogleサイトが最も優れていると判断したからではありません。もっと単純な理由です。
私自身が、すでに使っていたからです。
私が経営する会社のホームページは、GoogleサイトとBloggerを組み合わせて作っています。Googleサイトで会社のホームページを作り、Bloggerを技術情報発信に利用する。すでに実際に運用していたため、使い方も分かっています。
そこで、管理組合のホームページについても、まず同じ構成から始めました。新しいものを作るときに、自分がすでに経験している技術から始めるのは、ごく自然な選択でした。
Googleサイトには、無料でホームページを作るために必要な基本的な機能があります。Bloggerを組み合わせれば、継続的な情報発信もできます。
当初は、Googleサイトを管理組合ホームページ、Bloggerを住民からの情報発信に利用する構成を考えました。しかも、GoogleドライブやGoogleカレンダなど、ほかのGoogleサービスとの連携も容易です。
最初に考えていた「Googleの無料サービスだけで全部作る」という方針には、よく合っていました。
しかし、「みんなのお便り」を実際に作り始めると、会社のホームページを作る場合とは違った要求が次々に出てきました。
そこで、別の方法としてWordPress.comを試しました。最初からGoogleサイトほど使い慣れていたわけではありませんが、実際にページを作りながら使っているうちに、WordPressのブロックエディタにも慣れてきました。
そうなると、「使い慣れているからGoogleサイトを使う」という理由は、次第になくなり、むしろ、管理組合のホームページとして必要な機能を考えると、WordPressの方が都合のよいところが多くありました。
また、「みんなのお便り」の中心部分であるブログを扱うBloggerをプログラムから制御するためには、Google Cloudで提供されるBlogger APIを利用することになります。
しかし、無料枠のGoogleアカウントでは利用できないことが発覚しました。5000円の授業料を払うことになったのも、これを確認しているときに起きました。
それに比べ、WordPressは、ホームページとブログ／投稿機能を一つの仕組みで扱える。APIを使って外部のプログラムから投稿できる。そして、簡易的ではありますが、ページやブログをパスワードで保護することもできます。
管理組合のホームページでは、一般に公開する情報だけでなく、組合員だけに見せたい情報もあります。この点は、Googleサイト＋Bloggerで作っていた会社のホームページにはなかった要求でした。
その結果、管理組合ホームページの中心をGoogleサイトからWordPressへ移しました。
それならGoogleサイトを完全になくして、すべてWordPressへ移せばよいように思えます。現在ではWordPressのページ作成にも慣れており、ホームページを作る道具としてGoogleサイトに特にこだわっているわけではありません。
それでも現在のシステムにはGoogleサイトが残っています。理由は、Googleドライブです。
4.2. 文書保管――なぜGoogleドライブなのか
管理組合では、多くの文書を長期間保管する必要があります。総会資料、理事会資料、管理規約や細則、各種届出や様式、修繕・工事関係の資料、さらに写真などもあります。
WordPress.comの無料プランで利用できるストレージは1GBです。ホームページを公開するには十分利用できますが、管理組合の文書を長期間蓄積していく保管場所として考えると、1GBという容量には大きな制約があります。
一方、Googleアカウントでは、Googleドライブなどで利用できるストレージとして15GBの無料容量があります。MicrosoftのOneDriveなど、ほかのサービスも候補になりますが、今回のように無料で利用できる容量を重視すると、Googleドライブの15GBは大きな利点でした。
そこで、WordPressを「情報を見せる場所」、Googleドライブを「文書を保存する場所」と役割分担することにしました。
ところが、Googleドライブのフォルダをそのまま住民に開いてもらえばよい、とはなりませんでした。表示がグリッド形式になっていると、文書を探すには必ずしも見やすくありません。
パソコンやスマートフォンを使い慣れている人なら、自分で表示をリスト形式へ変更できます。しかし、「右上のボタンを押して、リスト表示へ変更してください」と高齢者にお願いするのであれば、第1章で考えたデジタル・バリアフリーから離れてしまいます。
システムの方で、最初から見やすくしておきたい。そこで、Googleドライブの内容を住民に見やすく表示するために、Googleサイトを利用することにしました。
本来なら、Googleドライブの内容をWordPressのページ内に直接表示できれば、Googleサイトを間に置く必要はありません。
しかし、WordPress.comの無料プランでは、必要なiframeタグを自由に組み込むことができません。
そのため現在は、WordPress → Googleサイト → Googleドライブという、一見すると少し回りくどい構成になっています。
Googleサイトを残したかったから、この構成にしたのではありません。WordPressの無料プランの制約、Googleドライブの15GBという利点、そして高齢者にもできるだけ簡単に文書を見てもらうこと。この三つを両立させようとした結果です。
したがって、Googleサイトは現在、管理組合ホームページの中心ではありません。Googleドライブに保存した文書を、住民に見やすく提示するための表示画面という役割を担っています。
4.3. 予定管理――なぜGoogleカレンダなのか
管理組合には、文書だけでなく予定の管理も必要です。総会、理事会、自治会の行事、草取り、ごみ収集、日本の祝日、その他の年間行事などがあります。
これらをホームページで確認できるようにするため、Googleカレンダを利用しています。
Googleカレンダには、管理する側が予定を登録・変更すれば、その内容をWebサイト側にも反映しやすいという利点があります。特別な予定管理プログラムを開発する必要もありません。また、カレンダを用途ごとに分けることで、複数の予定をまとめて表示できます。
実際に日本語、英語、中国語のホームページを作ると、当初想定していなかった問題も分かりました。言語に合わせてGoogleカレンダのすべての表示が自動的に都合よく切り替わるわけではありません。
また、予定を分類して色分けしようとしたときにも、当初考えていたような自由度がないことが分かりました。そこで、言語別、用途別にカレンダをどう分けるかを考え直しました。
これも、使ってみなければ分からなかった制約の一つです。
それでも、予定を登録・変更する側の操作性や、ホームページとの連携を考えると、現在はGoogleカレンダを利用するのが実用的だと判断しています。
4.4. AI――なぜGemini APIなのか
「みんなのお便り」の中心にあるのは、AIとの会話です。単に文章を生成できればよいわけではありません。
利用者がスマートフォンから自然に話しかけられること。AIがリアルタイムに会話できること。会話の内容から文章を作れること。日本語だけでなく複数の言語で会話できること。必要に応じて日本語へ翻訳できること。そして、これらをホームページ上のプログラムからAPIを通じて利用できること。こうした条件が必要でした。
開発時点で、これらの条件を満たし、さらに無料枠を利用して実際のシステムへ組み込むことができたのがGemini APIでした。
ここでも、Googleのサービスだから選んだわけではありません。Google Cloudの有料サービスを利用してシステムを構築することは、今回の「無料で運用する」という方針から対象外としました。
一方で、Gemini APIには無料で利用できる範囲がありました。そこで、AIについてはGemini APIを採用しました。
「みんなのお便り」では、Geminiが単に文章を生成するだけではありません。利用者の話を聞く。必要なことを質問する。内容を整理する。文章にまとめる。利用者から文句を言われれば直す。「もっと見た目を良くして」と言われれば、また考える。そして、多言語での会話や翻訳にも対応する。
第2章で説明した「ジェミニとおしゃべりしていたら文章になっていた」という利用方法そのものを支えているのがGemini APIです。
ただし、「みんなのお便り」は、将来にわたって必ずGeminiでなければならない、と考えているわけではありません。AIの進歩は非常に速く、利用条件や料金体系も変わります。
将来、同じ機能をより使いやすく、無料または低コストで提供できるAIが登場すれば、変更を検討する価値があります。
ただし、Googleドライブを別のストレージへ移す場合とは違い、AIの変更は簡単ではありません。リアルタイム音声会話、会話の制御、文章生成、多言語処理など、「みんなのお便り」の中心部分がGemini APIと密接に関係しているからです。
現在の構成の中では、最も簡単には置き換えられないサービスの一つです。
4.5. プログラム実行環境――なぜCloudflare Workersなのか
利用者のブラウザからGemini APIやWordPress APIを利用するためには、それらを安全につなぐプログラムが必要です。特に、APIキーなどの秘密情報を利用者のブラウザ側へそのまま置くわけにはいきません。
そこで、ブラウザと各サービスの間を中継するプログラムの実行環境としてCloudflare Workersを利用しています。
Cloudflare WorkersではJavaScriptを利用できます。ブラウザ側でもJavaScriptを利用しているため、同じ系統のプログラミング言語で、利用者側と中継側の処理を作ることができます。
また、このためだけに管理組合が専用のWebサーバーを契約し、OSやWebサーバーを構築して保守する必要もありません。そして、現在の利用規模では無料枠を利用できます。
Webシステムであれば、レンタルサーバーを契約し、PHPなどを使ってサーバー側の処理を書く方法もあります。もちろん、それでも実現できます。
しかし今回は、継続的なサーバー費用を発生させないことが大きな条件でした。そのため、無料枠で利用でき、JavaScriptで実装できるCloudflare Workersを採用しました。
ここでも、Cloudflare Workersが常にPHPより優れているという意味ではありません。今回の条件に合っていた、ということです。
4.6. 「一番よい製品」を選んだわけではない
ここまでを見ると、現在のシステムが少し複雑に見えるかもしれません。
WordPress、Googleドライブ、Googleサイト、Googleカレンダ、Gemini API、Cloudflare Workers。さらに、住民がそこへたどり着く入口としてQRコードやLINEも利用しています。
一つの会社のサービスですべてを統一した方が、構成だけを見れば簡単です。実際、最初はそうしようとしました。
しかし第3章で述べたように、Googleだけに依存した最初の構成は、Googleアカウントが停止されたことで一度に使えなくなりました。その経験もあり、現在は複数のサービスへ役割を分散しています。
そして、それぞれについて、無料で利用できるか、必要な機能があるか、住民にとって使いやすいか、ほかのサービスと連携できるか、実際に運用できるか、という観点から選んできました。
したがって、現在使っている製品やサービスを「これが一番優れた製品だから採用した」と評価しているわけではありません。
Googleサイトにも長所があります。WordPressにも制約があります。Googleドライブにも使いにくいところがあります。Googleカレンダにも、実際に使って初めて分かった制約がありました。Geminiも、いつでも思いどおりに動いてくれるわけではありません。Cloudflare Workersを使えば、システム構成も単純になるわけではありません。
それでも、それぞれの長所を利用し、短所を別のサービスで補うことで、現在の「みんなのお便り」を構成することができました。
製品にシステムを合わせたのではなく、実現したいことに合わせて製品を組み合わせた。
これが、現在の製品・サービスを選んだ理由です。
そして、無料という条件が変われば、選択も変わる可能性があります。その場合に、現在の構成のどこを残し、どこを変えるのか。それについては、次の章以降で考えていきます。
第5章 AIと一緒にシステムを作る
5.1. 最初はGeminiをプログラマとして使った
「みんなのお便り」の開発を始めた頃は、ChatGPT（正確には、ChatGPTのChat）と相談しながら、そのままChatからGeminiに指示をして、Geminiにプログラムを書いてもらっていました。
つまり、一人のAI（Chat）が人間（元IT技術者）と相談して仕様を決めると、下についている別のAI（Google Gemini）に作業指示するという体制で開発を進めていました。
「この機能を追加して」「このボタンを変えて」「次はこれもできるようにして」と伝えると、すぐにプログラムを書き直してくれます。最初のうちは、これは驚くほど便利でした。
ところが、システムが大きくなるにつれて問題が起き始めました。
新しい仕様を追加すると、3個くらい前に追加した仕様が消えている。
そんなことが何度も起きるようになりました。一つ直すと別のところが動かなくなり、それを直すと以前直したところが元に戻る。いわゆるデグレーション（退行）が頻繁に発生したのです。
まるで、仕事は速いけれど、以前決めた仕様を忘れてしまう未熟なプログラマに、設計書なしで口頭だけの追加作業を次々に頼んでいるような状態でした。
こちらも「それは前に直したでしょう」「なぜ元へ戻したの」とGeminiに文句を言う。Geminiも謝って直す。ところが、また別のところがおかしくなる。
とうとう、このやり方ではお手上げだと思うようになりました。
5.2. AIだから設計書はいらない、ではなかった
そこで開発方法そのものを考え直しました。
Geminiが以前の仕様を忘れることだけが問題なのではありません。こちらも、口頭だけで仕様を追加し続けていました。
人間のプログラマに仕事を頼む場合でも、システム全体の仕様書を渡さず、「昨日のものに今日はこれを追加して」「やっぱりここも変えて」と口頭だけで指示を続ければ、いつか破綻します。
AIだから何でも覚えていて、すべての仕様を矛盾なく維持してくれるだろう、と期待したこと自体に無理がありました。
そこで、プログラムを直す前に、まず設計を固めることにしました。
ここから、私の昔のシステム開発の経験が役に立ちました。何を仕様として決めなければならないのか。画面には何があるのか。利用者が操作すると何が起きるのか。Geminiはどこまで判断してよいのか。プログラム側で管理すべきものは何か。こうしたことを一つずつ整理しました。
会話開始、文章作成、投稿内容確認、キャンセル、投稿完了、強制終了などを状態として整理し、状態が変わる条件を確認し、クラス図や状態遷移図も作りました。
この設計作業を一緒に進めたのがChatです。設計書を作りながら、私もChatをいつしか「相棒」と呼ぶようになりました。
「この場合はどうなる」「この状態が抜けている」「それでは前に決めた仕様と違う」と、相棒と一つずつ仕様を確認していきました。
もちろん、相棒だから何でも信用したわけではありません。むしろ、設計書という形にしてみると、AI（Chat）にも意外なほど抜けや漏れがあり、私の説明を十分に理解していないこともありました。
会話をしていると、その場ではお互いに理解できているように感じます。しかし、設計書として書かせて、最初から最後まで読み直すと、「これは違う」「ここが抜けている」「この状態から次の状態へ移る条件が書かれていない」といった問題が見えてきました。
AIと会話が成立していることと、AIがシステム全体を正確に理解していることは同じではありません。
だから、AIが作った設計書をそのまま正しいものとして扱ってはいけない。人間が最初から最後まで読み、抜けや矛盾がないかを徹底的に確認する必要があることも分かりました。
それでも、一人で机に向かって設計書を書くのとはまったく違います。考えを話せば文章になる。疑問を投げれば一緒に考える。図にしたければ、すぐに形にする。間違いを指摘すれば、すぐに書き直す。
設計を考える相手が、いつでも隣にいるようなものでした。
だから私にとってChatは、単なるソフトウェアの名前ではなく、開発を一緒に進める「相棒」になったのです。
5.3. Codexに実装を任せたら、役割分担が変わった
設計書が一通り完成したところで、大きくやり方を変えました。
それまでプログラム作成を担当していたのは、主としてGeminiでした。しかし、完成した設計書をまとめてCodexへ渡し、その設計に基づいてプログラム全体を作ってもらうことにしました。
すると、一発ですんなり動きました。
それまで、機能を一つ追加するたびに別の機能が壊れ、デグレーションとの戦いを繰り返していたのが嘘のようでした。
ここで、AIの使い方について大きなことに気づきました。
AIが優秀なら設計書はいらないのではない。AIが優秀だからこそ、きちんとした設計書を渡した方が、その能力を発揮できる。
この時点で、開発における役割分担も一気に変わりました。
私とChatの「相棒」が仕様を考え、設計書を作り、徹底的に確認する。Codexには、まとまった設計に基づいてプログラムを実装してもらう。そしてGeminiは、完成した「みんなのお便り」の中で、住民と会話するAIとして働く。
AIを一人の万能な技術者として扱うのではなく、仕事によって役割を分ける。
これが、その後の開発方法になりました。
5.4. それでもAIは、とにかく速い
AIには間違いがあります。理解不足もあります。設計書にも抜けが出ます。したがって、人間のレビューは不可欠です。
しかし、ここでAIの欠点だけを強調するのも公平ではありません。
設計書に抜けがあれば指摘する。仕様の理解が違っていれば説明し直す。「ここを全部修正して」と頼む。すると、数分後には新しい設計書ができています。
プログラムについても同じです。かなり大きなソースコードであっても、仕様をきちんと与えれば、わずか数分で作り直します。
設計書でも、プログラムのソースコードでも、指示して5分もかからず形になる。
これは、やはり人間にはできない速度です。
1984年に公開された映画『ターミネーター』に登場したアーノルド・シュワルツネッガが扮したモデルT-800のような世界には、もちろんまだ到達していません。
しかし、かつてシステム開発に携わっていた者から見ると、現在のAIによる開発速度は、それだけでも十分に驚くべきものです。
私の感覚では、20年前と比較して10倍以上の速度で仕事を進められます。
AIが高速に作る。人間が確認する。問題を指摘する。AIが高速に直す。人間がもう一度確認する。
この繰り返しによって、一人で開発しているとは思えない速度で作業を進めることができました。
5.5. バージョン1（V1）からバージョン4（V4）へ――1か月弱の開発記録
「みんなのお便り」は、最初から現在の形で完成したわけではありません。V1からV4へ、実際に動かしながら段階的に作ってきました。
V1――まずホームページを作り、基本機能の実現性確認
V1では、Googleサイトを使って管理組合ホームページとしての基本的な枠を作りました。まず「住民へ情報を届ける場所」を作ることが中心でした。
さらに、Geminiと会話する機能の実装方法の確認をしておりました。
V2――Geminiとの会話とBloggerへの投稿
V2では、Geminiとの音声会話を組み込み、「話すだけで文章を作る」という「みんなのお便り」の中心となる機能へ進みました。さらに、作成した文章をBloggerへAPIで投稿する仕組みに挑戦し始めました。
ところが、この開発途中でGoogleアカウントが停止されました。理由ははっきり分かりませんでした。当時はGoogleの無料サービスだけで全体を構成しようとしていたため、一つのアカウントが止まったことで、それまでのシステム全体が使えなくなりました。
V3――Google一社依存をやめた
V3では構成を大きく変更しました。ホームページとブログエンジンをWordPressへ移し、プログラムの実行環境としてCloudflare Workersを採用しました。Googleだけですべてを構成する方式から、複数のサービスを組み合わせる現在の方式へ転換しました。
「みんなのお便り」が、現在につながる技術構成で実際に動くところまで進んだのがV3です。
V4――「動く」から「実際に使える」へ
V3で動くようになったものを、V4では住民が実際に使えるものへ仕上げていきました。
画面、ボタン、会話制御、投稿内容確認、添付ファイル、エラー処理、文章の反映、スマートフォンでの操作など、実際に使いながら何度も試験と修正を繰り返しました。
途中では、新しい機能を追加したために動かなくなり、安定していたバージョンへ戻して設計から考え直すこともありました。この時も、頭の良すぎるChatが複雑に考えてしまう仕様を私が単純化し、実現方法を楽にしましたので、難を逃れました。
5.6. そして、ついに多言語対応完成へ
そして現在の最新バージョンであるV4.0.10で、最後のバリアフリーである多言語対応を実現しました。この機能実現は、時間がかかるだろうと思ったけれど、意外にも基本的な機能は2日くらいで実装できました。
海外から来られた利用者が日本語を読む、話すことを前提にせず、その方が話しやすい言葉でGeminiと会話し、その言語で文章を完成させ、必要な段階で日本語へ翻訳する仕組みです。もちろん、日本人が作った日本語の文章も、英語と中国語へ翻訳し、一緒に投稿します。
また、その方の言葉で話せるだけでなく、操作性の面でも多言語対応しております。
はじめにGeminiが聞き取った会話から言語を特定し、画面の表示を全てその言語に変更します。これで、ボタン操作なども容易になるだろうと想定しています。
これによって、第1章で掲げた「操作、言葉、費用」という三つの障壁をできるだけ低くするという考え方が、かなり具体的な形になりました。
5.7. 1か月弱でここまで来られた理由
V1からV4.0.10までの道筋を見ると、決して一直線に完成したわけではありません。
作った。壊れた。戻した。設計し直した。利用するサービスまで変更した。AIの役割分担も変更しました。
それでも、1か月弱で実際に稼働できるシステムまで持ってくることができました。
これは、私一人の力では到底できなかったと思います。一方で、AIだけに任せても、おそらく現在のものにはならなかったでしょう。
人間には、何を作るのかを決める力があります。実際に使ってみて「これは使いにくい」と感じることができます。以前決めた仕様が消えていることにも気づきます。そして場合によっては、「もう一度、設計からやり直そう」と決断できます。
AIには、設計書やプログラムを、人間には到底できない速度で形にする力があります。
人間が考え、確認し、判断する。AIが圧倒的な速度で、それを形にする。
この組み合わせがなければ、「みんなのお便り」を一人（＋相棒）で、しかも1か月弱で現在のところまで作ることはできなかったと思います。
「みんなのお便り」はAIを利用するシステムです。
しかし同時に、AIがあったから作ることができたシステムでもあります。
第6章 システムの技術構成
6.1. 基本構成
現在の「みんなのお便り」は、一つの製品だけで動いているのではありません。利用者が見るホームページ、AIとの会話を処理するプログラム、文章を投稿する仕組み、文書保管、予定管理を、それぞれ適したサービスに分担させています。
利用者は、スマートフォンまたはパソコンのWebブラウザからWordPressのホームページを開きます。ホームページ上で動くJavaScriptが、Cloudflare Workersと通信します。
Cloudflare Workersは、利用者のブラウザとGemini API、WordPress APIの間を中継します。Gemini APIは音声会話、文章生成、翻訳などを担当し、WordPress APIは完成した「お便り」をWordPressの「お便り帳」へ投稿するために利用します。
基本的な処理の流れは、次のようになります。
↓
【WordPress上の画面／ブラウザ側JavaScript】
↕
【Cloudflare Workers（JavaScript）】
↕ ↘
【Gemini API】 【WordPress API → お便り帳へ投稿】
WordPressそのものがGemini APIへ直接接続しているというより、WordPressで提供する画面上のJavaScriptとCloudflare Workersが連携し、その先で各APIを利用する構成です。
6.2. 管理組合情報基盤
「みんなのお便り」は住民からの情報発信だけを独立して提供するものではなく、管理組合の情報基盤の一部として構成しています。
WordPressは、管理組合ホームページ、一般のお知らせ、組合員向けページ、ブログ機能、そして住民が投稿した「お便り帳」を提供する中心的な入口です。
Googleドライブは、総会資料、理事会資料、管理規約・細則、各種届出・様式、修繕・工事関係資料などの文書保管に利用します。WordPress.comの無料プランではストレージ容量に制約があるため、保存場所を分離しました。
Googleサイトは、Googleドライブ内の文書を住民に見やすく提示するために利用しています。現在では管理組合ホームページの中心ではなく、Googleドライブの表示画面としての役割です。
Googleカレンダは、総会、理事会、自治会行事、草取り、ごみ収集、祝日などの予定管理に利用します。予定を登録・変更すればWeb上の表示にも反映できるため、専用の予定管理プログラムを開発せずに済みます。
住民がこれらの情報へたどり着く入口として、掲示物などのQRコードやLINE公式アカウントのリッチメニューも利用します。
したがって、全体としては「WordPressを入口と表示の中心にし、Googleドライブを保存場所、Googleサイトを文書表示、Googleカレンダを予定管理、Cloudflare Workersをプログラム実行・API中継、Geminiを会話AIとして利用する」という役割分担になっています。
6.3. なぜPHPベースにしなかったのか
Webシステムのサーバー側プログラムをPHPで作ることは、現在でも一般的な方法です。今回Cloudflare Workersを採用したのは、PHPという技術を否定したからではありません。
PHPを利用するには、通常はPHPを実行できるWebサーバー環境が必要になります。レンタルサーバーを契約すれば比較的簡単に用意できますが、今回の大方針は「管理組合へ無償で提供し、できる限り継続費用を発生させない」ことでした。
そのため、現在の利用規模で無料枠を利用できるCloudflare Workersをプログラム実行環境として採用しました。
もう一つの理由は、JavaScriptです。利用者のWebブラウザ側ではJavaScriptを利用します。Cloudflare Workers側もJavaScriptを中心に実装できるため、ブラウザ環境のプログラムと中継側のプログラムで使用する言語を共通化できます。
これは「PHPよりJavaScriptが優れている」という比較ではありません。無料運用という条件、ブラウザとの親和性、開発・保守する技術をできるだけ共通化するという今回の条件に、Cloudflare Workersが適していたということです。
将来レンタルサーバーを利用する構成に変更する場合には、サーバー側機能をPHPなどへ移すことも可能です。しかし、Cloudflare Workersで安定して動作している処理を、サーバーを契約したという理由だけで書き直す必要はないと考えています。
6.4. APIによる連携
「みんなのお便り」の主要な機能は、複数のAPIを利用して実現しています。
Gemini APIとは、Cloudflare Workersを介して通信し、リアルタイム音声会話、文章生成、多言語対応、翻訳などを行います。
WordPress APIは、利用者とGeminiとの会話から完成したタイトルと本文、必要な添付情報などをWordPressの「お便り帳」へ投稿するために利用します。
Cloudflare Workersを中継する重要な理由の一つが、認証情報やAPIキーを利用者のブラウザへ置かないことです。ブラウザへ埋め込んだJavaScriptは利用者側から確認できるため、秘密にすべき情報をその中へ直接記載してはいけません。
そのため、秘密情報はCloudflare Workers側で管理し、利用者のブラウザは必要な処理だけをWorkersへ要求する構成にしています。
このように、APIを利用することで、WordPress、Gemini、Cloudflareという別々のサービスを、一つの住民向けシステムとして連携させています。
第7章 無料でどこまで運用できるか
7.1. 無料で運用するという設計条件
このシステムでは、管理組合が「使うのか、使えるのか分からないもの」に最初から費用を負担しなくても試せることを重視しました。
そのため、開発時点で利用可能な無料プラン、無料ストレージ、無料利用枠を組み合わせています。
ここでいう「無料」は、あらゆる条件で永久に費用が発生しないという意味ではありません。各社の無料枠には容量、利用回数、機能などの制約があり、サービス提供者が将来条件を変更する可能性もあります。
また、開発過程ではGoogleへ約5,000円を支払ったこともありました。したがって、開発の全過程で一円も支出していないという意味ではなく、完成した仕組みを管理組合が通常の規模で継続運用するための固定費を、できる限りゼロにすることを目標としています。
7.2. 現在利用している無料サービス
WordPress.comは、管理組合ホームページとブログ／投稿機能を無料で利用でき、APIによる外部プログラムからの投稿も利用できたことが大きな利点でした。一方、無料プランのストレージ容量は1GBであるため、文書保管はGoogleドライブへ分離しました。
Googleドライブは、Googleアカウントで利用できる15GBの無料ストレージを文書保管に利用しています。OneDriveなどの無料容量と比較しても、今回の用途では15GBが大きな利点でした。
Googleサイトは、Googleドライブの文書を住民に見やすく提示するために利用しています。Googleサイトそのものをホームページの中心として残したのではなく、無料のWordPressではGoogleドライブを希望する形で直接組み込みにくかったために残った構成要素です。
Googleカレンダは、管理組合や自治会の予定、ごみ収集、草取りなどを管理し、Webサイト上へ表示するために利用しています。
Cloudflare Workersは、ブラウザ側のJavaScriptと各APIをつなぐプログラム実行環境として、現在の利用規模では無料枠を利用しています。
Gemini APIは、「みんなのお便り」のリアルタイム音声会話、文章生成、多言語対応、翻訳を支える中核機能です。開発時点で、必要な機能をAPIから利用でき、無料枠で実装できたことが採用理由でした。
7.3. 管理組合で想定する利用規模
「みんなのお便り」は、大規模な商用Webサービスを想定して設計したものではありません。対象はマンションや団地の管理組合であり、利用者数や一日のアクセス数も一般的なインターネットサービスとは桁が違います。
この利用規模だからこそ、各サービスの無料枠を組み合わせて実用的な運用が可能だと考えています。
ただし、別の管理組合へ提供する場合には、戸数、アクセス数、AIとの会話量、保存する文書や画像の量などを確認し、無料枠の範囲で運用できるかを個別に確認する必要があります。
7.4. 月額2,000円程度を使えるなら
無料という条件を外し、たとえば月額2,000円程度の運用費を許容できるのであれば、技術構成には別の選択肢が生まれます。
レンタルサーバーを利用し、WordPress本体と管理組合の文書・画像を十分な容量のサーバーへまとめれば、文書保管のためのGoogleドライブは必ずしも必要ではなくなります。
Googleドライブを住民に見やすく表示するために利用しているGoogleサイトも、その場合は不要にできます。
Cloudflare Workersが担当しているサーバー側処理をPHPなどへ書き直し、レンタルサーバーへ統合することも技術的には可能です。しかし、すでに安定して動作しているWorkersを、構成要素を一つ減らすためだけに書き直す必要はありません。
GoogleカレンダについてもWordPress側の予定管理機能などへ置き換えることは可能ですが、管理する側の登録・変更のしやすさを含めて比較する必要があります。
一方、Gemini APIは単なる保存場所や表示サービスではありません。「みんなのお便り」の会話そのものを支えているため、ほかのAIへ変更する場合にはAPI仕様、音声会話、会話制御、多言語処理などを含めてプログラムを見直す必要があり、現在の構成では簡単には置き換えられない部分です。
つまり、現在の構成は唯一の正解ではありません。無料という条件が変われば、採用するサービスも変えることができます。
7.5. 無料サービスは将来も同じとは限らない
無料サービスを利用する以上、料金体系、無料容量、APIの利用条件、機能などが将来変更される可能性があります。
したがって、このシステムでは特定の製品名そのものを絶対条件とするのではなく、「ホームページ」「文書保管」「予定管理」「AI」「プログラム実行環境」という役割ごとに考え、必要であれば別のサービスへ移行できるようにしておくことが重要です。
本章に記載した無料枠、容量、料金その他の利用条件は、2026年9月4日現在の条件を前提としています。導入時には、必ず各サービスの最新の利用条件を確認する必要があります。
第8章 セキュリティと継続運用
8.1. 何を守るのかを最初に考える
管理組合の情報には、一般に公開してよいものと、組合員だけに見せたいもの、さらに外部へ漏れてはならないものがあります。
セキュリティを考えるときには、すべての情報を同じ方法で扱うのではなく、情報の性質によって公開方法と保護方法を変える必要があります。
たとえば、一般のお知らせや行事予定のように広く知らせたい情報、組合員向けの総会・理事会関係情報、本当に第三者へ見せてはならない個人情報や機密情報では、必要な保護の強さが異なります。
8.2. APIキーをブラウザへ置かない
Gemini APIなどを利用するためのAPIキーや認証情報は、利用者のブラウザ側へ直接置きません。
ブラウザで実行されるJavaScriptは、利用者が内容を確認することができます。その中にAPIキーを書けば、秘密情報として保護できません。
そのため、秘密情報はCloudflare Workers側で管理し、ブラウザはWorkersを介して必要な処理を実行します。
WordPress APIについても、投稿に必要な認証情報を利用者へ直接見せないことを前提に構成しています。
8.3. WordPressのパスワード保護
WordPressでは、組合員向けページについて簡易的なパスワード保護を利用できます。
これは、一般公開ページと組合員向けページを分けるためには有用です。一方で、利用者ごとに厳密な権限を管理する高度なアクセス管理ではありません。
したがって、WordPressのパスワード保護だけで、あらゆる機密情報を安全に保管できると考えるべきではありません。
なお、必要に応じて、パスワード設定した全てのページやブログのパスワード変更を行えるように仕組みを用意してあります。
8.4. GoogleサイトとGoogleドライブは保護されていない
現在の構成で特に注意しなければならないのが、GoogleサイトとGoogleドライブです。
WordPressの「組合員専用」ページをパスワードで保護していても、その先にあるGoogleサイトまで同じパスワードで保護されるわけではありません。
現在の公開方法では、GoogleサイトのURLを知っていれば、そのサイトから公開対象となっているGoogleドライブ内の文書を見ることができます。
したがって、「GoogleサイトへのリンクをWordPressの組合員専用ページにしか置いていないから安全」と考えることはできません。
URLは第三者へ伝えられる可能性があります。リンクを知らないはずだということ自体を、アクセス制御として扱うことはできません。
これは、無料サービスを組み合わせた現在の構成における重要な制約の一つです。
8.5. 本当に見られてはならないPDFはファイル自体を保護する
GoogleサイトやGoogleドライブへ置く文書のうち、本当に第三者へ閲覧させてはならないPDFについては、リンクの置き場所だけに頼らず、PDFファイル自体を保護する必要があります。
必要に応じて、PDFを開いて読み出すためのパスワードと、編集・変更等を制限するためのパスワードを設定します。
つまり、WordPressの簡易的なパスワード保護、Googleドライブでの公開範囲の管理、そして必要なPDF自体のパスワード保護を組み合わせて考えます。
ただし、PDFへパスワードを設定すれば、どのような情報でも公開クラウドへ置いてよいという意味ではありません。本当に漏えいしてはならない個人情報や機密情報については、そもそもインターネット上へ置かないという判断も必要です。
8.6. 情報を四つに分けて考える
実際の運用では、情報を次のように分類して考えると分かりやすくなります。
① 一般公開してよい情報――管理組合からのお知らせ、行事予定など。
② 組合員向けだが、万一URLを知られても重大な問題にならない情報――WordPressの組合員向けページなどで提供する情報。
③ ファイル自体の保護が必要な情報――Googleドライブ等へ保存する場合には、PDF自体にも読み出し・変更制限のパスワードを設定する情報。
④ 原則として公開クラウドへ置かない情報――個人情報や、漏えいした場合の影響が大きい機密情報。
この区分は固定的なものではありません。管理組合が文書の内容と漏えい時の影響を判断して、適切な保護方法を決める必要があります。
8.7. 一社に依存しないことも継続運用の対策
開発当初は、Googleの無料サービスだけで全体を構成する計画でした。しかし、開発途中でGoogleアカウントが停止され、それまでの仕組み全体が使えなくなる経験をしました。
また、開発中にはWordPress側でもアカウントやサイトが無効化される経験がありました。
この経験から、セキュリティだけでなく継続運用の観点でも、一つのサービスや一つのアカウントだけにすべてを依存することにはリスクがあると考えるようになりました。
現在は、ホームページ、文書保管、AI、プログラム実行環境を複数のサービスへ分散しています。構成は複雑になりますが、一つのサービスの問題で全体を失う危険を減らすという意味があります。
無料サービスには、サービス停止、アカウント停止、利用条件変更など、自分たちだけでは制御できないリスクがあります。重要な文書については別途バックアップを持ち、サービスが使えなくなった場合の移行方法も考えておく必要があります。
第9章 誰でも使えるようにする
9.1. 無償提供を目指す
「みんなのお便り」は、私たちの管理組合だけで使うために閉じた仕組みにするのではなく、希望する他の管理組合にも無償で提供できるようにしたいと考えています。
特に、小規模な管理組合では、住民向けの情報システムへ大きな費用をかけることは容易ではありません。無料サービスを組み合わせて実際に運用できる今回の経験には、ほかの管理組合でも利用できる部分があると考えています。
9.2. ホームページの構成は自由でよい
他の管理組合へ移植する場合、私たちのホームページと同じページ構成にする必要はありません。
団地の規模、管理組合の組織、自治会との関係、公開したい資料、住民構成などは、それぞれ異なります。
したがって、ホームページのページ構成やメニューは導入する管理組合が自由に決め、「みんなのお便り」の会話・投稿機能や必要な連携部分を組み込めるようにするのが望ましいと考えています。
9.3. 最初から完璧な移植ツールは作らない
将来は、できるだけ簡単にセットアップできるようにしたいと考えています。
しかし、現時点であらゆる管理組合に対応できる汎用的なセットアッププログラムを先に作るつもりはありません。
まず今回の説明資料を完成させ、情報を公開します。そして実際に「使ってみたい」という管理組合が現れたら、その管理組合へ移植する作業を行いながら、何を共通化できるのか、何を設定項目にすべきなのかを考えます。
実際の利用者がいない状態で想像だけで汎用化するより、具体的な移植を経験しながらポータビリティを高めていく方が、実用的なものになると考えています。
9.4. 情報技術者との協業とオープンソース化
この仕組みを情報技術者にも見てもらい、改善や移植に協力してくれる人が現れるのであれば、プログラムをオープンソースとして公開することも考えています。
個人的にはGPL系のライセンスに親しみがありますが、ライセンスを先に固定する必要はないと考えています。
実際に協力してくれる人が現れた段階で、どのような形で公開し、改良した成果をどのように共有するのがよいかを相談して決めたいと思います。
重要なのは、特定の会社だけが保守できる仕組みにすることではなく、技術を理解する人が参加し、必要に応じて改良できる余地を残すことです。
9.5. まず情報を公開する
現在の第一の目標は、完璧な配布パッケージを作ることではありません。
まず「なぜ作ったのか」「どのように作ったのか」「何に失敗したのか」「何を選び、なぜ選んだのか」「無料でどこまでできたのか」を、この資料で公開することです。
完成した資料は、私の会社の技術情報としても公開し、YouTubeなどを利用した情報発信も検討しています。
その情報を見て、同じような問題を抱えている管理組合や、技術面で協力したい人が現れたときに、次の段階へ進みます。
「みんなのお便り」そのものと同じように、他の管理組合への提供方法についても、最初から完成形を決めるのではなく、実際に使いながら育てていきたいと考えています。
第10章 他の管理組合への無償提供
10.1. 実際に運用しているシステムを基礎にする
「みんなのお便り」は、机上で考えた試作品ではありません。実際の管理組合でホームページを構築し、住民が利用することを想定して、試験と修正を繰り返しながら作ってきたシステムです。
他の管理組合へ提供する場合も、この実際に構築・運用している仕組みを基礎にします。完成した製品を一方的に配るのではなく、現場で使って分かった問題や改善点を反映しながら提供していきたいと考えています。
10.2. 希望する管理組合へ無償で提供する
この仕組みを使ってみたいという管理組合があれば、当面は無償で提供したいと考えています。
小規模な管理組合にとって、効果が分からない情報システムへ最初から費用をかけることは容易ではありません。まず使ってみて、住民に役立つかどうかを確かめる。そのための入口をできるだけ低くすることは、第1章で述べた「デジタル・バリアフリー」の考え方にもつながります。
ただし、各サービス事業者の料金や無料枠、導入先固有の作業など、将来発生し得る実費まで永久に無償であることを保証するものではありません。
10.3. 最初から完全な汎用システムを目指さない
現時点で、あらゆる管理組合にそのまま導入できる完全な汎用システムを先に作ろうとは考えていません。
管理組合によって、戸数、建物構成、組織、自治会との関係、住民構成、公開したい情報、利用しているサービスは異なります。実際の利用者がいない状態で、それらをすべて想定して設定項目を作ると、かえって複雑なシステムになります。
まず希望者が現れたときに実際に移植してみる。その過程で必要になったものを整理する。この方法で十分だと考えています。
10.4. 実際の移植から共通部分を見つける
導入希望の管理組合へ移植すると、現在の仕組みのうち、そのまま使える部分と、管理組合ごとに変更しなければならない部分が具体的に分かります。
たとえば「みんなのお便り」の会話、投稿、翻訳などは共通化しやすい部分です。一方、管理組合名、ホームページのページ構成、メニュー、保存する文書、カレンダの分類などは、それぞれの管理組合に合わせる必要があります。
こうした実際の移植を重ねながら、共通化すべき部分と管理組合固有の部分を整理していきます。
10.5. ホームページは各管理組合が自由に作ればよい
他の管理組合へ導入するときに、私たちのホームページと同じ構成を再現する必要はありません。
ホームページは、それぞれの管理組合が住民に何を伝えたいかに合わせて自由に設計すべきものです。「みんなのお便り」は、そのホームページの中で住民が情報を発信するための一つの機能として組み込めればよいと考えています。
したがって、ポータビリティを高めるということは、ホームページを同じ形にすることではなく、共通機能を異なるホームページへ容易に組み込めるようにすることです。
10.6. 将来はセットアップを簡単にする
移植経験が増え、共通部分と個別部分が整理できれば、将来はセットアップ作業を簡略化できます。
管理組合名、WordPressの接続先、利用するAI、カレンダ、表示言語などを設定するだけで導入できる形が理想です。
しかし、その仕組みを先に想像だけで作るのではなく、実際の導入を経験しながら必要な設定を決めていきます。
第11章 技術者との協業と将来構想
11.1. 情報技術者にも参加してもらいたい
今回のシステムは、一人の元情報技術者とAIを中心に作りました。しかし、完成したからといって、これが最良の設計であるとは考えていません。
他の情報技術者に実際の仕組みや設計書を見てもらえば、私たちが気づいていない問題や、もっと良い方法が見つかるはずです。
セキュリティ、操作性、アクセシビリティ、多言語対応、保守性など、さまざまな観点から検証・改善に参加してもらえることを期待しています。
11.2. ソースコードの公開とオープンソース化
協力してくれる技術者が現れ、他の管理組合でも利用できる形へ発展していくのであれば、将来的にはソースコードの公開も考えています。
個人的にはGPL系のライセンスに親しみがあります。しかし、現時点でライセンスを先に固定する必要はないと考えています。
実際に協力する人が現れた段階で、改良した成果をどのように共有するか、第三者による利用や再配布をどのように扱うかを相談し、適切なライセンスを決めたいと思います。
11.3. 第三者が引き継げるものにする
システムが特定の一人しか理解できない状態では、管理組合で長く利用することはできません。
ソースコードだけを公開しても十分ではありません。仕様書、状態遷移、設定内容、導入手順、運用上の注意事項なども整理し、別の技術者が見れば仕組みを理解し、必要に応じて修正できる状態にする必要があります。
第5章でAIとの開発のために作った設計書は、AIへ仕事を頼むためだけでなく、将来、人間が引き継ぐための資料としても役立つはずです。
11.4. 特定のAIへ固定しない
現在の「みんなのお便り」ではGemini APIを利用しています。リアルタイム音声会話、多言語対応、翻訳、文章生成、API利用、そして開発時点で無料枠を利用できることを総合して選びました。
しかし、Geminiを永久に使い続けること自体が目的ではありません。
今後、同等以上の機能を持ち、管理組合が無料または低い費用で利用できる優れたAIが登場する可能性があります。その場合には、API仕様や会話制御などの変更範囲を確認したうえで、別のAIへ変更できる余地を残したいと考えています。
重要なのは製品名ではなく、住民ができるだけ簡単に、自分の言葉で情報を発信できることです。
11.5. ポータビリティを高めながら育てる
他の管理組合への移植、技術者による検証、AIや外部サービスの変更可能性を考えると、ポータビリティは一度完成すれば終わるものではありません。
実際に利用する管理組合が増えるたびに、固有部分を切り離し、設定で変更できる部分を増やし、導入手順を改善する。その積み重ねによって、少しずつ移植しやすいシステムへ育てていきたいと考えています。
第12章 実際に使ってみませんか
12.1. まず使ってみる
ここまで、「みんなのお便り」をなぜ作ったのか、どのような問題にぶつかったのか、どのサービスを選び、AIとどのように開発したのかを説明してきました。
しかし、このシステムの価値は、説明資料だけでは決まりません。
実際の管理組合で住民に使ってもらい、本当に便利なのか、使いにくいところはないか、使われない機能は何かを確かめて、初めて評価できます。
もし同じような問題を感じている管理組合があれば、まず実際に使ってみませんか。
12.2. 導入希望者と一緒に検証する
当面、希望する管理組合への提供は無償で行う考えです。
完成品を渡して終わりではなく、実際のホームページや運用方法に合わせて移植し、利用して分かった問題を一緒に確認したいと考えています。
その経験は、導入した管理組合のためだけではなく、「みんなのお便り」を他の管理組合でも使いやすくするための改善にもつながります。
12.3. 情報技術者の協力も歓迎する
管理組合への導入だけでなく、この考え方や技術に関心を持つ情報技術者の参加も歓迎します。
「ここは危ない」「この方法の方が簡単だ」「この設計なら別の管理組合へ移しやすい」といった指摘も含め、第三者の視点が加わることで、より安全で使いやすいものにできると考えています。
AIを利用した住民向けシステム、無料サービスを組み合わせた管理組合の情報基盤、デジタル・バリアフリーという考え方のいずれかに関心があれば、一緒に検討していただければと思います。
12.4. 問い合わせについて
導入を希望する管理組合、技術面で協力いただける方からの問い合わせ方法は、この資料を公開するWebサイトに掲載します。
この資料の完成後は、会社の技術情報として公開するとともに、YouTubeなどでの紹介も検討しています。
最初から大きな仕組みにするつもりはありません。まず一つの管理組合で作ったものを、次の一つへ移してみる。そこで分かったことを直す。その繰り返しで十分です。
「みんなのお便り」も、そのようにして育ってきました。
情報技術を住民に合わせる。AIを、人に難しい操作を覚えさせるためではなく、人の話を聞くために使う。
この考え方が、ほかの管理組合でも役に立つかどうか。
次は、実際に使って確かめてみたいと思っています。
以上