いすみ市議会議員一般選挙
<><><>
新たに挑戦する若い候補者の皆さん。当選した暁には、何があっても「現状維持」に固執する議員たちに取り込まれることなく、初心を貫いてください。
これまでの慣習にとらわれず、市民の目線に立って、より良い議会へと変えていく。その若い力と行動力に期待しています。
Androidアプリの解析からAPIへの侵入――本当に問題だったのは何か
<><><>
Webサービスへの不正アクセスを調査したJPCERT/CCは、攻撃者がAndroidアプリの配布ファイルや解析ツール、スクリプトなどを用いて標的を調べていたとみられる痕跡を発見しました。AIも利用されていたようです。
ここからは推測ですが、攻撃者はアプリを解析し、サーバーとの通信に使われるAPIの仕様を調べたのではないでしょうか。通信先のURLやパラメータ、認証方法などを把握し、アプリを介さずAPIを直接呼び出して、弱点を探った可能性があります。
そのAPIは、REST APIだったかもしれません。REST APIとは、アプリがHTTP通信を通じてサーバーのデータを取得・更新するための、広く使われる仕組みです。例えば、画面に利用者情報を表示する際にも使われます。呼び出し方が分かれば、正規のアプリを使わずに要求を送ることもできます。
しかし、APIの存在や仕様を調べられること自体は、脆弱性ではありません。アプリは利用者の端末で動く以上、解析されることを前提に設計すべきです。重要なのは、APIを直接呼ばれても、サーバー側の認証・認可や入力検証によって不正操作を防げるかどうかです。
生成AIの進歩は、こうした調査の効率も高めています。守る側も、AIを活用して想定外の呼び出しや権限の逸脱を繰り返し検証する必要があります。
問われているのは、アプリの中身を知られたことではありません。中身を知られても安全なシステムになっているか、という設計と検証の質なのです。
生成AIを、過去の常識で理解していませんか?
<><><>
生成AIをめぐる議論には、数年前の技術水準を前提にしたものが少なくありません。しかし、その進歩は驚くほど速く、半年前の知識さえ古くなることがあります。
2020〜2022年は、文章や画像、プログラムを「生成するAI」の時代でした。2023年には検索や外部ツールを使うようになり、2024年には高度な推論やコンピューター操作へと進化しました。
大きな転換点は2025年です。開発環境の構築からビルド、テスト、エラー解析、修正まで実行する「仕事を遂行するAI」が登場しました。さらに2026年には、複数のAIエージェントが設計、実装、検証などを分担し、協調して働く仕組みも実用化が進んでいます。
これは単なる性能向上ではなく、AIの役割そのものの変化です。人間の役割も、作業を細かく指示することから、目標や制約条件を定め、成果を検証することへと変わりつつあります。ただし、AIがテストを実行しても、成果の正しさが保証されるわけではありません。
こうした変化は、生成AIに質問して回答を読むだけでは理解できません。実際に仕事を任せ、条件を変え、結果を検証し、修正を繰り返す。その実践を通して初めて、現在の能力と限界が見えてきます。
問題なのは、生成AIの利用経験が少ないことではありません。古い知識を更新しないまま、現在の技術を評価してしまうことです。 それでは新たな可能性を見逃すばかりか、周囲にも誤った認識を広めかねません。
大切なのは、過去に何ができたかではなく、今、何ができるようになったのかを理解することです。
技術が日々進化している以上、私たち自身の理解もまた、進化し続けなければならないのではないでしょうか。
先日、「いすみ議会だより」を「広報いすみ」から独立させ、内容もさらに充実させてはどうかと、いすみ市議会へ提言しました。
議会事務局から丁寧な回答をいただき、「議会だより」は以前は独立した冊子として発行されていたものの、より多くの市民に読んでもらうことを目的に、平成22年から「広報いすみ」に組み込まれたとのことでした。
それから約16年。現在の議会だより編集委員会でも、独立した冊子のあり方を含め、さまざまな意見が出ており、今後検討していくとのことです。
今回提案した、賛否が分かれた議案の論点を分かりやすく伝えること、市民の声や厳しい意見も取り上げる双方向の紙面づくりについても、議長や編集委員へ伝えていただけることになりました。
議会中継が実現した今、その次の一歩として、「議会だより」も市民にとって、より身近で分かりやすいものへ変わっていくことを期待しています。
大原はだか祭り
<><><>
小浜八幡神社の神輿は、寄せては返す波に揉まれながら、20分以上も海の中にありました。
神輿を守り、支え、声を掛け合う氏子たち。海と人と神輿がひとつになるような、力強い「汐ふみ」の光景です。
そして海から上がっても、祭りの勢いは止まりません。神輿を担いだまま浜辺を何度も駆け回り、砂浜には掛け声と足音が響き渡ります。荒い波にも負けない熱気――小浜八幡らしい、勇壮なひと幕でした。
ミラドールの注文管理システムを、アクティブ・スタンバイの冗長構成にしました。
通常は現用系で処理し、障害が発生すると待機系へ切り替えて運用を継続します。そして今回こだわったのは、切り替わるところまでで終わらせなかったこと。障害を起こした現用系が復旧したことを確認すると、システム全体の状態を整えたうえで、正しく現用系へ戻るところまで考慮しています。
冗長化は「障害時に切り替われば完成」ではありません。障害の発生から切り替え、復旧、そして平常状態への復帰まで、一連の流れがきちんと閉じて初めて安心して使える仕組みになります。
小さな店の注文管理システムとしては、少々やり過ぎかもしれません。それでも「動く」だけでなく、「壊れたとき、そして直ったときにどう振る舞うか」まで考えてしまうのは、技術者の性分なのかもしれません。