作って終わりじゃない。PHP騒動から考えるAI時代のモノづくり

はじめに

PHP騒動（PHP2Shell）をきっかけに、改めて考えたことがあります。

SNSでは、よくあるホームページを例に「なぜ、どこにPHPを使う必要があるのか？」という趣旨の投稿も見かけました。

たしかに、非エンジニアやHTML、CSSを少し知っている方々からすると、サーバーサイドの仕組みまで意識する機会は少ないかもしれません。

今回、首相がXで緊急発信したこともあり、不特定多数の人たちを巻き込む大きな話題に発展した印象があります。こうした動きの中で、先ほどのような意見が出るのも自然なことだと思います。

しかし同時に、昨今は「AIで非エンジニアでも爆速開発」といった流れも日に日に強くなっていると感じます。

Web技術への理解が十分でないままAIによる開発が広がっていくことに、少し危機感を覚えました。

今回述べたいのは、「釣った魚に餌を与え続けることや、調理器具の手入れも大切。つまり、作るだけでなく、作った後にどう保守・運用していくかも考慮すべき」 ということです。

対象読者は「AI開発に関心のある非エンジニア」を軸に、最近Web制作や開発に関わり始めた方々も想定しています。

「作れる」と「実用に耐えるものを作れる」の大きな差

生成AIの進化によって、ちょっとしたツールやWebアプリなら、AIと対話しながら「作れる」時代になりました。

ただし、「作れる」と「実用に耐えるものを作れる」には大きな差があります。

自分にとって便利なツールやアプリを、善意や承認欲求から他者に配布したり、インターネット上に公開したりする機会も、今後ますます増えていくかもしれません。

しかし、その一方で、本人が十分に理解できていないリスクを抱え込む恐れもあります。
特に、サーバーなどのインフラや、その周辺知識への意識が薄い場合は注意が必要です。

今回は、PHP騒動をきっかけに、AI時代のモノづくりと運用保守について、個人的に考えたことを書いてみます。

AIがあれば、誰でもソフトウェアを作れる時代

AIがコードをポンと作ってくれる時代ですが、生成されたものをそのまま使えるとは限りません。

たとえば、画面上でユーザー名とパスワードを入力し、ログインできる仕組みを作ること自体は、AIの助けがあれば比較的簡単です。

しかし、実際にサービスとして公開するなら、それだけでは足りません。

• パスワードを安全に扱えているか
  • そもそも、自分のサービスでパスワードを管理する必要があるのか？
• 認証だけでなく、適切な認可も実装されているか
  • ユーザーが別のユーザーの情報にアクセスできてしまうバッドケースを想定できているか？
• セッション管理に問題はないか
  • 手軽さを優先して、認証トークンなどの機密情報をブラウザ側に安易に保存していないか？ XSSなどによって読み取られるリスクを考慮しているか？
• 不正アクセスへの対策や検知はできているか
  • ログを確認する方法や保存場所を理解しているか？ 不正アクセスが発生した場合の影響を把握できているか？
• 想定外の入力や操作に対応できるか
  • 入力値の検証や、出力先に応じたエスケープ処理を理解しているか？ 悪意のある入力によって何が起きるのか、想像できるか？

これはあくまで一例であり、省略している観点もあります。実際には、こうした部分も含めて、もっと広く深く考える必要があります。

AIは実装を助けてくれますし、テストコードの作成やセキュリティ上の懸念点の洗い出しにも活用できます。

ただし、作れたことと、それを安心して使えることは別の話です。

これはAIを使うかどうかに関係なく、ソフトウェア開発において以前から存在していた問題でもあります。

PHPを使っていなければ、対応しなくてもいい？

二番煎じではありますが、今回のPHP騒動についても要点だけ触れておきます。

今回の一件は、アプリケーションのコードやフレームワーク固有の脆弱性ではなく、PHP本体、つまりプログラムの実行環境に存在する脆弱性です。
PHPがインストールされている場合でも、それだけで直ちに脆弱性の影響を受けるとは限りません。

そのため、アプリケーションのコードを修正するだけでは解決せず、影響を受けるPHPの実行環境を適切に更新する必要があります。

ただし、実際に誰が更新を行うのかは、利用しているホスティングサービスや運用体制によって異なります。

※ホスティング事業者が実行環境の更新を担う場合もありますが、利用者側でPHPのバージョン変更などが必要になる場合もあります。誰がどこまで対応するのかは、利用しているサービスや契約、運用体制によって異なります

「PHPを使っていないから大丈夫」と思い込まず、サーバー環境にPHPが存在するのか、影響を受けるバージョンなのか、そして誰が対応する責任を持っているのかを確認することが大切です。

エックスサーバーへの感謝

蛇足ですが、筆者は常日頃からアップデート・アップグレードと挙動チェックを習慣づけています。
今回も、利用しているホスティング先であるエックスサーバーの対応のおかげで、筆者側で必要となる作業はほとんどありませんでした。エックスサーバー様には感謝申し上げます。対応お疲れ様でした。

アップデートやアップグレードの習慣化は、正直なところ面倒です。
とはいえ、通常の更新状況を定期的に確認し、更新後に主要な機能が正常に動くかをチェックしておくことには意味があります。
問題が発生した際に、現状を把握しやすくなったり、原因を特定する手がかりを得やすくなったりするからです。

週1〜2回などの定期的な確認だけで、すべての脆弱性に対応できるわけではないので、緊急性の高いセキュリティ情報が出た場合は、定期作業を待たずに影響を確認することも重要です。

また、侵害が疑われる場合は、更新だけで解決したと判断せず、ログや不審な変更なども確認する必要があります。こういった際にホスティング先のサポートが必要になる場合も多いです。

話を戻します。

個人的に触れておきたいのが、実際に使っているコードだけを確認しても、運用上のリスクを把握しきれない場合があるという点です。

たとえば、静的サイトのコンテンツ自体はHTMLとCSSで構成されていて、PHPを使っている認識もない。

だから、PHPに関する対応は必要ない。そう考えたくなるかもしれません。

しかし、コンテンツでPHPを使っていないことと、サーバー環境にPHPが存在しないことは別の話です。

PHPがインストールされている場合でも、それだけで直ちに脆弱性の影響を受けるとは限りません。ただし、実行環境やバージョン、設定などを確認しなければ、リスクの有無は判断できません。

つまり、Web制作や開発では、作ったものだけでなく、それが動いている環境まで含めて把握する必要があるということです。

今回の一件は、AIによる開発のあり方を考える良いきっかけにもなるのではないかと感じています。

釣った魚に餌をやり続ける

ここからは、本記事の主旨である「作るだけでなく、作った後にどう保守・運用していくかも大切」という点について、「釣った魚に餌をやり続ける」という比喩を使って考えてみます。

ソフトウェアは、一度作って公開すれば、それで終わりというわけではありません。
使い続けるのであれば、定期的に面倒を見る必要があります。

たとえば、次のようなものです。

• 使用しているライブラリやフレームワークの更新
• セキュリティ上の脆弱性への対応
• 実行環境やミドルウェアの更新
• 外部APIの仕様変更への対応
• エラーや障害の調査・修正

こうした作業は、ソフトウェアが存在し、利用され続ける限り発生する可能性があります。

先ほどのPHPの例も、まさにこの話につながります。

仮に、制作したWebサイトそのものがPHPに依存していなかったとしても、サーバー環境にPHPが残っているなら、環境の状況を確認し、必要に応じて関係者へ情報共有したり、対応を依頼したりする必要があるかもしれません。

そして、PHP自体の更新も重要です。

これは自分が作ったコードと直接的な関係はありません。
しかも、ユーザーから見れば機能的・見た目的にも何も変わらない作業かもしれません。

それでも、保守対象は自分のサービス = 自分が直接書いたコードだけではないので、サービスを維持するためには必要となるのです。

アップデートやアップグレード、保守もAIで！

たしかに、AIを使えばこれらの作業も効率化できるでしょう。

ただし、どこをどう対処させるのか、アップデートしてよいのか、更新によって不具合が発生しないかといった判断は、人間側にも求められます。

開発のコストが下がったとしても、運用保守のコストまで同じように下がるとは限りません。

作ったものが増えるほど、面倒を見る対象も増えていく。
これは、AIを活用した開発でも意識しておきたいポイントだと思います。

釣った魚は、早めに食べるとリスク軽減？

長期間使い続けるサービスでは、簡単に保守を放棄するわけにはいきません。

一方で、釣った魚に餌を与え続けるのは面倒、という方もいるかと思います。
そもそも、すべてのソフトウェアを長期間運用する必要があるのでしょうか。

たとえば、以下のような「ちょっとしたもの」です。

• 一度だけ実行するCSVデータの加工スクリプト
• 大量の画像のalt属性をチェックするツール
• データ移行のために作った一時的なプログラム
• 特定の作業を自動化するための小さなスクリプト
• アイデアを検証するためのプロトタイプ

これらは、目的を達成した時点で役割を終えることもあります。

そうであれば「最初から長期運用を前提とした構成にする必要はなく、目的を達成したら使い終える」で良いでしょう。食べるために釣ったのであれば、釣って（作って）食べて（使い切り）で終わりです。

ただし、一時的なツールとして作ったものが、いつの間にか業務に欠かせない存在となっているケースもあります。

その場合、運用に発展するので当初は想定していなかった保守や引き継ぎが必要になります。

使い捨てのつもりで作ったものが、気づけば手放せない仕組みになっている状態が続くと、後から自分の首を絞めることにもなりかねません。

作った時点での用途だけでなく、その後どう使うかにも注意したいところです。
作る段階で『本当にその場限りのものなのか』『後から別の用途に流用する可能性はないか』を考えておくと、将来の保守や引き継ぎが楽になることもあります。

そもそもWebに公開する必要はあるのか？

ここまでの話で、Web開発では自分が直接作った部分とは関係のないところで対応が必要になる場合がある、ということを説明してきました。

そこで、もうひとつ考えてほしいのが、作ったものをインターネット上に公開する必要があるのかということです。

先ほど、自分にとって便利なツールを善意や承認欲求から他者に配布したり、公開したりする機会が増えるかもしれない、と書きました。

ただ、公開することによって生じる管理の負担やリスクを、きちんと理解しておくべきだと思います。

たとえば、DIYで自分の部屋で使う、自分が使いやすい家具を作ったとします。
それをわざわざホームセンターに持っていって、不特定多数の人に配布する必要はないですよね？

ソフトウェアも、これと似たところがあると思います。

自分のローカル環境、つまりPC内で使うのであれば、必ずしもサーバーを用意したり、Webサービスとして公開したりする必要はありません。

もちろん、ローカルで動くからといって、リスクがゼロになるわけではありません。外部ライブラリの脆弱性や、ローカルファイルへのアクセス、データの破損など、考慮すべき点はあります。

それでも、インターネットに公開する必要がないものを公開しなければ、公開範囲に起因するリスクや管理対象を減らせる可能性があります。

どうしても同僚や他者に配布したい場合は、実行に必要なツールや環境構築の手順、使用している技術とそのバージョン、更新方法、脆弱性への注意点なども合わせて渡すのが、お互いにとって良いと思います。
つまりは、 「説明書を用意しましょう」 という話です。

作った本人が使い方を理解していることと、受け取った人が安全に使い続けられることは別です。
自分以外の人に使ってもらうのであれば、その人が困らないための情報も含めて渡すことを意識したいところです。

調理器具のメンテナンスも必要

ソフトウェアを動かすための環境やツールにも、メンテナンスが必要です。

たとえば、次のようなものです。

• PythonやNode.jsなどの実行環境
• ReactやVue、Next.jsなどのフレームワーク
• 使用している外部ライブラリやパッケージ
• サーバーやホスティングサービスの個人・組織の設定
• データベースや外部APIとの接続

料理に例えるなら、ソフトウェアが料理で、実行環境やライブラリは調理器具のようなものです。
料理を作り終えた後も、調理器具を使い続けるなら、洗ったり、手入れしたりする必要があります。

ソフトウェアも同じで、コードだけでなく、それを動かすための環境にも目を向けなければなりません。

Cloudflare、Vercel、Netlify、AWS などのホスティングサービスやマネージドサービスを利用すれば、サーバー管理やインフラの一部をサービス提供者に任せられます。

ただし、それによって責任が完全になくなるわけではありません。
利用しているサービスの仕様変更や料金体系の変更、サービス終了などに伴い、設定変更や移行などの対応が必要になることもあります。

また、使う技術やサービスを増やしすぎると、それだけ管理対象も増えてしまいます。
AIを使えば複雑な構成も作れてしまうからこそ、必要以上に複雑なものを作らないことも重要です。

個人用の小さなツールであれば、シンプルな構成にするだけで、将来の自分が助かることもあると思います。

まとめ

生成AIの進化によって、ソフトウェアをただ作るハードルは、これからも下がっていくでしょう。

しかし、作ったものを適切に活用し続けるという視点も必要だと思います。

• 長く使うものなら、保守や運用を考える
• 一時的なものなら、目的を達成したところで手放す
• 公開する必要がなければ、ローカルで完結させる
• 他者に配布するなら説明書（使い方や必要な環境、更新方法）も用意する

そして、使い続けるための環境についても、無理なく管理できる構成を選ぶ。

作れるから作るのではなく、何のために作り、どう使い、どう維持していくかまで考える。

これが、AIを活用したモノづくりにおいて、意識しておきたいことのひとつだと思います。

今回のPHP騒動も、「ただ作るだけが開発じゃない」ということを、感覚的に理解する良いきっかけになればいいなと思います。

作ること自体のハードルが下がった今だからこそ、何を作るかだけでなく、どう使い、どう維持し、いつ手放すのか。そんなところまで含めて、これからのモノづくりを考えていきたいですね。

ここまで読んでいただき、ありがとうございました。