はじめに
生成 AI の進化によって、これまで触れたことのない言語やフレームワークを使って、アプリケーションを形にしやすくなってきました。普段は C# や Azure を中心に開発している私も、GitHub Copilot と一緒に PHP アプリケーションを作ろうとしています。
きっかけは、「AI がコードを書き、AI がレビューする時代に、人間の仕事は何になるのだろう」という疑問です。コードを書く部分を AI に任せられるなら、開発者はもう言語を学ばなくてよいのでしょうか。AI が自分のコードをレビューしてくれるなら、人間によるレビューは不要なのでしょうか。
先にお伝えしておくと、この記事を書いている時点では、PHP アプリの開発はこれからです。登壇ではアプリを実際に作り、実装・レビュー・改善の過程を検証する予定ですが、ここに書くのはその実践を終えた後の体験談ではありません。PHP Conference Kansai に提出したプロポーザルを出発点に、スライドを書く前に「何を確かめたいのか」「どんな視点で開発を振り返るのか」を整理するシナリオです。
この記事では、実際に起きたかのような成功例や失敗例を先回りして書くのではなく、これからの開発で観察したいことを考えます。要件定義、品質保証、アクセシビリティ、セキュリティ、設計判断という観点を通して、AI に任せる仕事と、人間が判断・責任を担う仕事の境界を探っていきます。
あえて、経験のない PHP を選ぶ
私は普段 C# や Azure を中心に扱っており、PHP 開発の経験はほとんどありません。今回、あえて馴染みの薄い言語を選んだのは、AI に実装を助けてもらえば、未知の言語でもアプリケーションを作れるかを試すためです。
もう一つ確かめたいことがあります。AI がコードを書いてくれるとき、私はそのコードを何を根拠に受け入れたり、修正を求めたりするのでしょうか。使い慣れた言語なら、いつもの書き方や既存の設計を手がかりに判断できる場面があります。知らない言語では、その安心感をそのまま使えません。
ただし、開発で決めなければならないことは、構文だけではありません。何を作るのか、誰が使うのか、何を満たしたら完成とするのか。これらは PHP の文法を覚えれば自動的に決まることではありません。AI が構文や実装案を補助できても、アプリケーションの目的や制約は、別に考える必要があります。
PHP を選んだのは、言語の学習そのものを目的にするためではありません。未経験の技術に向き合いながら、言語知識と開発者の責務を切り分けて考えるためです。開発後に振り返るときも、「AI が PHP のコードを書けたか」だけではなく、「そのコードが目的に合っていると、私はどう確かめたのか」を問いにしたいと思います。
作り始める前に、要件を言葉にする
AI にコードを生成してもらうには、まず依頼を伝えます。しかし、「アプリケーションを作ってください」と依頼するだけでは、完成した状態を決められません。AI は動作するコードを提案できても、何を解決するためのアプリなのか、誰にとって使いやすいものにしたいのかを、私の代わりに決めることはできません。
たとえば、フォームを備えたアプリを作るとします。画面に入力欄と送信ボタンがあり、送信後に結果が表示されれば、ひとまず機能はできたように見えるかもしれません。しかし、入力に誤りがあったときに何を伝えるのか、入力内容が失われないか、キーボードだけで操作できるか、意図しないデータを受け取らないか、といった条件も考える必要があります。
これは特定の PHP 機能についての話ではありません。要件として伝えられていない条件は、コードにもテストにも反映されにくいものです。AI が実装を速く進められるほど、曖昧な要件のまま作り始めた場合に、何を基準に結果を評価するのかが見えにくくなります。
そのため、開発を始める前に、少なくとも目的、利用者、期待する振る舞い、制約、受け入れ条件を整理しておきたいです。すべての実装方法を先に決めるのではなく、何を解決したいのか、どの状態を成功とするのかを明確にする。そこを決めて初めて、AI の提案を目的に照らして確認できます。
AI に任せたいこと、任せきれないこと
慣れない言語で開発するにあたり、AI には構文や書き方の説明、実装候補、エラーの原因調査、テストや改善の観点の洗い出しを手伝ってもらうつもりです。人間だけで進めると調査から始める場面で、次に試す案が得られるのは大きな助けになるでしょう。
ただし、提案を受け取れることと、その提案を採用する判断まで任せられることは別です。AI が示したコードが PHP の構文として成立していても、アプリケーションの要件に合うとは限りません。実行できることと、安全であること、利用者にとって分かりやすいこと、将来の変更に耐えられることも、それぞれ別の確認です。
開発を始める前の時点で考えている役割分担を、次のように整理しました。これは実践後の評価ではなく、開発中に検証するための仮説です。
| 観点 | 🤖 AI に手伝ってもらいたいこと | 👤 人間が引き受けること |
|---|---|---|
| 要件 | 要件の整理、曖昧さや不足の洗い出し | 何を作り、何を作らないかを決める |
| 実装 | コードの候補、構文の説明、修正案 | 目的と制約に合う実装を選ぶ |
| 品質 | テスト観点や確認手順の候補 | 完成条件を定め、結果を確かめる |
| アクセシビリティ | 画面や操作の改善案、確認項目 | 誰がどのように使うかを考え、利用体験を評価する |
| セキュリティ | 既知のリスクや注意点の指摘 | 扱うデータや利用状況に応じてリスクを判断する |
| 設計 | 選択肢とトレードオフの説明 | 保守性や変更の見通しを踏まえて選択する |
この表は、AI にできることと人間にできることを完全に二分するものではありません。AI は人間の確認を助けられますし、人間も実装の細部を検討します。開発後に見直すときには、想定した役割分担が実際に機能したか、AI に任せた仕事と人間が判断した仕事の境界を更新したいです。
AI のレビューを、品質の証明にしない
「AI がコードを書き、AI がレビューする」という流れは、自然に感じるかもしれません。書き手とは別にレビューを依頼し、問題を指摘してもらえば、確認が完了したように思えることもあります。これから AI にレビューを依頼するときは、結果をそのまま採用するのではなく、指摘をどう扱うかも観察したいです。
レビューの指摘が妥当かどうかを判断するには、そもそも何を満たす必要があるのかを知っていなければなりません。AI が改善案を提案しても、その変更が要件を満たすために必要なのか、別の問題を生まないかは、アプリケーションの目的や利用者を踏まえて判断する必要があります。
テストも同じです。テストが成功したという結果は、実行したテストが確認した範囲で問題が見つからなかったことを示します。では、そのテストは必要な振る舞いを確かめているでしょうか。失敗する条件や、利用者にとって重要な操作を含んでいるでしょうか。実装後に、テストの結果だけでなく、テスト範囲をどう決めたかも振り返るつもりです。
AI のレビューを、見落としを減らし考えるきっかけを増やすために使えるかは、実際に試して確かめたいことです。一方で、レビューを受けた事実を品質の証明に置き換えることはできません。コードとテストの意味を理解し、何が確認済みで、何が未確認なのかを説明できる状態にすること。その責任は、変更を受け入れる人間に残ると考えています。
アクセシビリティを確認項目にとどめない
アプリケーションの品質を考えるとき、画面が表示され、主要な操作ができるかだけで終わらせたくありません。利用者がどのような環境で、どのような操作方法を使っているかによって、同じ画面でも使いやすさは変わります。
たとえば、マウスで操作できることと、キーボードだけで同じ機能に到達できることは同じではありません。入力エラーを表示することと、どの項目に何の問題があるのかを利用者が理解できることも同じではありません。これらは今回のアプリで確認した結果ではなく、開発時に考えたい例です。
AI に確認項目や実装案を出してもらうことはできるでしょう。それでも、どの利用者のどの困難を解消したいのか、どの状態を確かめるべきなのかを決めるには、要件と利用の文脈が必要です。AI に「アクセシビリティに対応して」と依頼しただけで終わらず、確認したい利用体験を人間が定め、実装後に実際の操作で確かめたいと思います。
登壇で扱うときも、「対応を依頼した」という事実だけではなく、どの観点をどう検証し、どこは未確認として残ったのかを分けて伝えたいです。自動化できた範囲と、人間が確かめる必要のある範囲を区別することが、品質を誠実に共有するために必要です。
セキュリティは、指摘の数では測れない
セキュリティについても、AI にレビューを依頼すればすべてのリスクがなくなるわけではありません。コードの一部に既知の問題がないかを尋ねたり、入力や権限の扱いを確認したりするのは有用だと考えられます。一方で、何を保護すべきなのか、どのデータを扱うのか、誰がどの操作を許されるのかが曖昧なままだと、指摘の妥当性を評価することも難しくなります。
たとえば、同じ入力欄でも、受け取る内容や保存先、利用者の権限によって確認すべきことは変わります。汎用的なチェック項目を実行することと、そのアプリケーション固有のリスクを理解することは別です。実際に何を扱うかを決めたあとで、どのリスクが関係するのかを洗い出す必要があります。
開発後に確認したいのは、AI が何件指摘したかだけではありません。どの前提に基づいて確認したのか、どこまで確かめられたのか、残るリスクをどう扱うのかです。AI の指摘が少ないことを安全の根拠にせず、利用とデータに対する責任としてセキュリティを考えたいと思います。
設計判断は、選択肢を並べるだけでは終わらない
AI は複数の実装方法を提案できます。候補を比較し、それぞれのメリットや注意点を説明してもらえば、自分だけでは気づかなかった選択肢に出会えるかもしれません。
ただ、選択肢を並べることと、ひとつを選ぶことは別の仕事です。今の要件を満たすかだけでなく、あとから仕様を変えやすいか、他の人が理解できるか、問題が起きたときに調べられるかといった条件を考える必要があります。どの条件を優先するかは、アプリケーションの目的や規模、開発・運用する人たちによって変わります。
慣れた言語であれば、既存の設計やチームの習慣に照らして判断しやすいかもしれません。未経験の言語では、その前提をすぐに使えないことがあります。だからこそ、AI の説明を読んだうえで、自分が何を理解できていて、何がまだ確かでないのかを区別したいです。
AI に実装案を考えてもらうことと、その案を採用することは別の段階です。開発時には、将来の変更や保守まで考えたときに、どの選択肢を選び、なぜそう決めたのかを記録しておきたいと思います。設計判断に必要な情報を AI から得られるかだけでなく、最後に判断するための知識や確認が何かも振り返る予定です。
言語が変わっても、責務の境界は変わらない
PHP を使えば、C# とは構文も慣習も異なります。新しい環境に慣れるための学習は必要です。AI は、その学習を助けたり、書き始めるまでのハードルを下げたりしてくれるでしょう。
しかし、言語が変わっても、開発者が答えるべき問いは残ります。なぜこのアプリを作るのか。誰が使うのか。何をもって正しく動くと判断するのか。どのリスクを許容するのか。変更後に何が起きるかをどう確かめるのか。
この問いへの答えは、PHP や C# の構文の中にはありません。言語やフレームワークは、目的を実現するための手段です。AI によって未知の手段を扱いやすくなっても、目的を決め、結果を評価し、採用した変更に責任を持つ必要はなくならない、というのが今の私の仮説です。
開発前の段階で結論を決めつけず、実装・レビュー・改善を進めながら、この仮説を確かめたいと思います。PHP の知識がどこまで必要だったのか、AI の説明だけでは判断できなかった場面があったのか、人間の判断が結果にどう影響したのか。実際に起きたことと、事前に考えていたことを分けて記録するつもりです。
スライドに向けて、何を記録しておくか
プロポーザルでは、実装、レビュー、改善の過程を通じて、AI だけで解決できたこと、AI が苦手だったこと、人間の判断が必要だったことを共有すると書きました。スライドにする前に、開発中は次の三つの問いを記録していきたいです。
- 何を AI に任せたのか — 構文の説明、実装の候補、レビュー、改善案など、どんな依頼をし、どこで助けになったのか。
- 何を確かめたのか — 生成されたコードやテストについて、目的に合うと判断するためにどんな根拠を集めたのか。
- 何を人間が決めたのか — 要件、品質、アクセシビリティ、セキュリティ、設計のうち、どんな判断を人間が引き受けたのか。
それぞれについて、うまくいったことだけでなく、AI の提案を採用しなかった場合の理由や、確認できなかった範囲も記録します。具体例と評価を分けておけば、後から話を組み立てるときに、印象だけでAI の能力や限界を断定するのを避けられます。
PHP はこの話の入口です。聞き手に持ち帰ってほしいのは PHP の書き方だけではなく、自分が普段使っている言語や AI 開発の場面でも、何を任せ、何を確かめ、何に責任を持つのかを問い直す視点です。
おわりに
この記事を書いている時点で、PHP アプリの開発はこれからです。そのため、ここに書いたことは、実装や検証の結果ではなく、これから確かめたい問いと仮説です。
AI は、慣れない言語で開発を始めるときの力強い助けになると期待しています。コードの候補を得たり、レビューの視点を増やしたり、改善のきっかけを得たりできるでしょう。一方で、要件を決めること、品質を測る基準を用意すること、利用者への影響やセキュリティ上のリスクを考えること、設計のトレードオフを選ぶことは、AI の提案を受け取るだけでは完了しないと考えています。
言語が変わっても、何を AI に任せ、何を人間が任せきれないと判断するのか。その判断の軸は変わらないのではないか。これからの開発を通じて、その考えがどこまで確かめられるかを見ていきます。
スライドを作るときには、事前に立てた仮説だけでなく、実際に起きたこと、確認できたこと、最後まで分からなかったことを分けて共有したいです。AI 時代に人間が担う責務について、PHP アプリを作る過程から考えていきます🧭