コードの書きやすさは、開発言語を選ぶ際の大切な基準です。では、コードを書く仕事をAIに任せると、言語の選び方はどう変わるのでしょうか。AIを使うと実装の手間を減らせますが、出来上がったコードの確認は必要です。変更の影響を調べ、意図したとおりに動くかを確かめなければなりません。AIが処理の構造を把握しやすいか、人が変更内容を確認できるかも、選定の基準になります。新規開発でも既存システムの改修でも、実装後の動作確認や運用中の保守を見据えて技術を選ぶ必要があります。
【関連記事】AI開発の品質指標とは？E2Eテストの評価基準
Webシステムの構成をどう考えるか
AIが短時間でコードを作れても、どの処理を変え、どの動作を確かめるのかは決めておく必要があります。画面と業務処理の役割を分けておくと、修正する箇所をAIに具体的に伝えられます。修正後も、画面と業務処理をそれぞれの役割に沿ってテストできます。
画面の操作と業務処理を分ける
Webシステムは、利用者が操作する画面と、その操作を受けて動く処理から成り立っています。画面の表示や操作を担う側をフロントエンド、業務処理やデータ管理を担う側をバックエンドと呼びます。例えば、受注一覧の表示や入力欄の操作はフロントエンドの仕事です。入力内容が受注の登録条件を満たすかを判定し、金額を計算してデータを保存する処理は、バックエンドが担います。両者の役割を分けると、画面の使い勝手の改善と業務ルールの変更を、それぞれの目的に沿って進められます。
フロントエンドとバックエンドは、APIを通じてデータをやり取りします。APIは、別のプログラムから機能を呼び出すための窓口です。受注を登録するAPIでは、送信する項目と、登録後に返す情報を決めます。入力に誤りがあった際の応答も決めておきます。画面側はこの仕様に従ってデータを送り、業務処理側は決められた形式で結果を返します。画面を修正しても、APIとのやり取りが変わらない範囲であれば、バックエンドの処理はそのまま使えます。
フロントエンドの処理には、サーバーで動かすものもあります。例えば、業務処理を呼び出すAPIへ要求を中継し、返されたデータを画面に表示しやすい形に整える処理です。Next.jsでは、こうした中継や整形も実装できます。ブラウザーでは利用者の入力を受け付け、画面を表示します。画面側のサーバーではAPIとの通信を中継し、受注の登録や金額計算などの業務処理はバックエンドで行います。それぞれの処理が何を担当し、どこで動くかを整理しておくと、修正が必要な箇所を判断しやすくなります。
AIに任せる範囲と確かめる範囲を明確にする
受注一覧の列の順序を変える際は、対象画面のコードと表示要件、API仕様をAIに渡します。表示に必要なデータをすでにAPIから取得できるのであれば、表示処理だけを修正します。金額計算や登録処理を変える必要はありません。修正後は、列が指定した順序で並び、値が正しく表示されるかを確かめます。登録条件を変える際は、変更後の条件を示す資料と、対象の業務処理のコードを渡します。このように、修正内容に応じて必要なコードや資料をそろえ、変更する箇所と確認する動作を具体的に伝えます。
確認する内容も、各処理の役割に合わせて整理します。画面側では、取得したデータを正しく表示できるか、利用者の入力を受け付けられるかを調べます。入力に誤りがあったときの案内が適切かも確認します。業務処理側では、入力条件に沿って判定されるか、金額計算とデータの保存が正しく行われるかを確かめます。APIを直接呼び出すテストでは、送信するデータと、その入力に対して返るべき結果を用意します。用意したデータをAPIに送り、実際の応答が想定した結果と一致するかを確かめます。この方法で、画面操作を経由せずに処理を確認できます。AIに実装やテストの作成を依頼する際にも、この入力と結果の組み合わせを示せます。
画面側と業務処理側を個別に確認した後は、両者を接続して一連の動作を試します。各部分が動いていても、項目の意味やエラーの扱いが食い違うと、画面からは正しく利用できません。例えば、金額をやり取りする際は、税込みと税抜きのどちらで扱うかを、画面側と業務処理側でそろえる必要があります。API仕様を変更する際は、画面側と業務処理側の実装にも、その変更が反映されているかを確認します。入力から登録、結果の表示までを通して試し、保存した内容も照合します。役割を分ける構成では、接続部分の管理と、つないだ状態でのテストも必要になります。
「書く手間」から「変更と検証」へ
少ない記述で機能を作れる言語を使うと、コードを書く負担が軽くなります。この利点は、技術を選ぶ理由の一つになります。AIに実装を任せると、人がコードを書く負担は減りますが、生成されたコードの確認は必要です。処理が複雑に入り組んでいると、記述量が少なくても、変更の影響を調べるために時間がかかります。技術を比較する際は、コードの記述にかかる手間だけでなく、修正箇所の調査や動作の検証にかかる手間も考慮しましょう。書きやすさとともに、構造を理解しやすく、動作を確かめやすいことも重要です。
処理ごとの役割を決めておくと、変更内容に応じて修正箇所を絞れます。画面の表示を変える際は表示処理を、登録条件を変える際は業務処理を修正します。AIに依頼する際も、対象の箇所を具体的に指示できます。完成形を文章で伝えるとともに、API仕様に定めた入出力の条件や、動作を確かめるためのテストも示します。修正後は、依頼した内容とAIによる変更を比べ、意図しない箇所まで変わっていないかを確認します。想定外の変更があった際は、その理由を調べます。さらに、API仕様に合っているかを確認し、テストで動作を確かめます。
技術を選ぶ際には、AIが修正箇所を見つけやすいか、変更後の動作を確かめる手段があるかも確認しましょう。コードや仕様に、処理を理解するための情報が残っているかを調べます。画面と業務処理の役割を分け、接続仕様を決めておくことも有効です。ファイルの配置に関する規約は、修正箇所を探す手掛かりになります。データの形を機械的に検査できると、変更によって生じた誤りも見つけやすくなります。Next.jsやTypeScriptには、こうした規約や検査の仕組みがあり、AIによる修正と、その結果の確認に役立つと考えられます。
バックエンドを選ぶ基準
AIに修正を任せる際は、AIが対象のコードの場所と、そこで扱うデータの形を把握できるようにしておく必要があります。フレームワークの規約や型情報は、AIがこうした内容を理解する手掛かりになります。修正後は実際に動かして確かめ、エラーの内容をAIに渡して、さらに修正を進めることもできます。
標準的な選択肢となったNext.js
Next.jsは、画面を作るためのライブラリーであるReactを基盤としています。アプリケーションの構成を定める枠組みと、開発に必要な機能を備えたフレームワークです。Reactの公式ドキュメントでは、新しいアプリやWebサイトを開発する際に、フレームワークの利用を勧めています。その選択肢として、Next.jsのApp Routerを紹介しています。Reactを使うフロントエンド開発では、標準的な選択肢の一つです。画面を作るほか、サーバー側でAPIとの通信を中継し、データを整える処理も実装できます。業務処理はAPIを介してバックエンドに任せ、画面に必要な処理をNext.jsでまとめて開発できます。
Next.jsでは、ファイル名と配置に規約があります。ページの内容を定義するpage、共通のレイアウトを定義するlayout、読み込み中の表示を定義するloading、エラー時の表示を定義するerrorというように、ファイル名に応じて役割が決まっています。URLとフォルダー構造にも対応関係があります。AIは、こうした規約を手掛かりに修正箇所を探せると考えられます。例えば、読み込み中の表示を変える際は、その表示を担当するファイルを規約に沿って探せます。
Next.jsには、AIが正しい使い方を調べ、コードを修正するための支援機能もあります。導入したバージョンに対応する資料を同梱し、AIから参照できるようにしています。さらに、Next.js 16以降の開発サーバーは、実行中のエラーやログをAIへ提供できます。その接続に使うMCPは、AIが外部ツールとやり取りするための共通規格です。MCPに対応した環境では、AIに資料を参照させ、コードの修正から実行結果の確認までを行わせることができます。エラーが発生した場合は、その内容に基づいて修正し、再び動作を確認します。
TypeScriptはAIのコード理解と検証を助ける
TypeScriptは、JavaScriptに型の仕組みを加えた言語です。型は、数値や文字列といった値の種類や、データの形を表します。受注情報であれば、受注番号は文字列、金額は数値、備考は省略可能な文字列、といった指定ができます。処理をひとまとまりにした関数では、受け取る値や返す値にも型を付けられます。AIは型を読むことで、その関数が何を受け取り、どのようなデータを返すかを把握しやすくなります。型で示されたデータの形を手掛かりに、その関数を呼び出す処理や、結果を画面に表示する処理の実装を考えられます。
型検査では、コードに書かれた項目名や値の種類に食い違いがないかを、実行前に調べます。例えば、数値を返すはずの処理が文字列を返していると、その誤りを検出できます。検査で指摘された内容をAIに渡し、該当するコードを修正させます。修正後は、もう一度検査を実行します。GitHubも、型によってコードの曖昧さが減り、AIが生成したコードの誤りを本番利用前に見つけやすくなると説明しています。検査の範囲や厳しさは設定によって変わるため、開発時にはその設定も確認します。
APIとの接続にも、型情報を使えます。バックエンドにもTypeScriptを使う場合は、APIの入出力を表す型を、フロントエンドと共有して管理できます。Javaを使う場合には、API仕様からTypeScriptの接続コードを生成する方法があります。OpenAPI Generatorは、そのためのジェネレーターを提供しています。いずれの方法でも、接続部分で扱うデータの形を明示できます。APIを変更する際は、仕様と型、生成したコードをそろえて更新します。
型検査のほかに、実行時の確認も必要です。TypeScriptの型情報は、実行用のJavaScriptに変換する際に取り除かれます。外部から受け取る値を検証し、APIが仕様どおりのデータを返すかも確かめます。また、金額が数値であると分かっても、その金額が正しいかまでは型で判断できません。計算方法は、業務仕様に沿ったテストで確認します。
バックエンドはNode.jsか、Java＋Spring Bootか
Node.jsは、JavaScriptをサーバーなどで動かすための実行環境です。バックエンドをTypeScriptで作る構成にも使えます。フロントエンドと言語をそろえると、データを表す型や、コードの書き方を共通化しやすくなります。画面の表示処理から業務処理まで、同じ言語で書かれたコードを読める点も利点です。一方、Node.jsが提供するのは実行環境であり、アプリケーション内の処理の配置や役割分担までは定めません。これらは、AIへ伝える実装規約とともに、開発する側で決めておく必要があります。
Javaによる開発では、Spring Bootが選択肢になります。単独で動作するアプリケーションを作るための機能を備え、組み込みサーバーも利用できます。必要なライブラリーをまとめて導入する仕組みや、自動設定も提供しています。運用時には、指標による監視やヘルスチェックを行えます。設定をアプリケーションの外部で管理する機能も利用できます。既存のJavaコードや、Javaシステムを運用してきた経験がある場合は、それらを生かせます。画面側にNext.jsとTypeScriptを使い、業務処理はJavaで実装する組み合わせも取れます。
バックエンドを選ぶ際は、業務に必要な処理と、既存資産との接続方法を整理しましょう。テストの方法、運用体制、保守期間も確認します。記述量の多いコードも、AIの支援によって人が書く負担を減らせます。その分、修正後の検証や保守のしやすさが、技術選定でより重要になります。既存のJava資産を生かすか、TypeScriptで言語をそろえるかは、これらの条件を踏まえて判断します。また、担当者がその言語を理解し、AIに修正を指示できるかも確かめます。生成されたコードを読み、動作を検証しながら保守を続けられる組み合わせを選びましょう。
AIは古いシステムの延命も助ける
AIは、新しいコードを書く仕事にも、既存のコードを調べて直す仕事にも使えます。AIによって調査や修正の手間が減ると、既存システムの維持費用も下がる可能性があります。全体を作り直すか、必要な部分を改修するかを判断する際は、今のシステムで残せる処理を調べます。そのうえで、全面刷新と部分的な改修にかかる費用を比較する必要があります。
既存システムの改善ではMVCも有効
従来よりWebシステムではMVC設計がよく使われてきました。これはシステムをModel・View・Controllerに役割を分ける考え方です。Modelはデータや業務ルールを扱い、Viewは表示を担います。Controllerは要求を受け付け、必要な処理へ振り分けます。受注システムであれば、金額計算や登録条件の判定をModel側に、一覧や入力欄を表示する処理をView側に配置します。Controllerは画面からの要求を受け、処理の結果を返します。役割が整理されていると、既存コードを調べる際にも処理の流れを追いやすくなります。
MVCの役割分担を手掛かりにすることは、AIに既存システムを改修させる際も有効です。入力欄の表示を変える際はViewを、金額の算出方法を変える際はModel側の処理を調べます。Controllerも確認し、画面からの要求がどの処理に渡るかをたどります。修正を始める前に、AIにこの流れを調べて説明させ、開発担当者がコードと照合します。そのうえで、必要な箇所の変更を依頼します。変更後は、同じ入力に対して、以前とどのように結果が変わったかを確認します。処理が役割ごとに整理されていると、変更前後でどの処理の結果を比べるかも決めやすくなります。
MVCが採用されているシステムでは、既存のビジネスロジックを維持したまま画面のみを改修するという選択肢もあります。まず既存の設計を調べ、どのビジネスロジックをそのまま利用できるかを確認します。Spring MVCには、処理の戻り値をAPIの応答として返す仕組みがあります。既存の受注処理をAPIから呼び出せるようにすると、Next.jsで作った画面からも使えます。新しい画面では、APIから受け取ったデータを表示し、登録時にはAPIへ要求を送ります。ビジネスロジックを維持しながら、必要な画面から順に改修できます。
AIによって既存コードを保守しやすくなる
設計資料が揃っていない場合、既存システムの改修には現在のコードを理解する手間が必要です。AIは、コードの内容を説明したり、関連する処理を探したりする作業を支援できます。GitHubの公式資料では、Copilotを使った保守の例として、重複コードの整理、テストの追加、古い依存ライブラリーの更新などを紹介しています。例外処理のコードを整理したり、ばらつきのある書き方を統一したりする際にも、AIの支援を受けられます。従来は担当者が手作業で進めていた調査や修正の一部を、AIに支援させることができます。
例えば、受注の入力条件を変更する際は、現在の判定処理や例外処理をAIに調べさせます。どの条件で登録を受け付けるかを説明させ、担当者が実際のコードと照合します。次に、変更前の動作を調べるためのテストを用意します。登録される入力と、登録が拒否される入力を試し、それぞれの結果を記録します。この調査を基に、変更する箇所を絞ってコードを修正します。変更後は、新しい入力条件が反映されているかを確認します。既存のテストも実行し、変更する予定のない処理が以前と同じように動くかを確かめます。
何を正しい仕様としてテストすべきかをAIが自動で判断することはできません。現在のコードにも誤りが残っている可能性があるため、現行の動作をそのまま正解として扱うことはできません。担当者が業務要件を確認し、どの入力に対してどのような結果が返るべきかをAIに伝える必要があります。AIは、その条件に基づくテストの作成や、変更後の動作確認を支援できます。GitHubも、AIが生成したコードを人が確認し、要件や設計意図に合っているかを確かめるよう求めています。担当者はAIの説明やテスト結果を確認し、変更の理由と影響を把握したうえで、修正を採用するかを判断します。
維持・改修の費用が下がると刷新の判断も変わる
全面刷新は、新しいコードを書くだけでは終わりません。データ移行や、動作確認のコストも伴います。入力条件の判定や例外処理も、既存システムの設計を確認して作り直す必要があります。AIによってコードを書く負担が減っても、これらの作業まで省けるわけではありません。一方、AIは既存コードの調査や改修にも使えるため、今のシステムを直して使い続ける費用も下がる可能性があります。全面刷新と継続利用を比べる際は、それぞれの開発・改修費用と、その後の保守・運用費用を含めて判断する必要があります。
例えば、金額計算に問題がなく、一覧画面の使い勝手を改善したい場合は、既存の計算処理を維持したまま画面を改修できます。画面の表示に必要なデータをAPIで取得できるようにし、そのAPIを利用する新しい画面を作ります。登録条件も変える必要がある場合は、既存のコードを調べ、該当する処理を改修します。残す部分と変える部分を整理すると、動作確認が必要な範囲も明確になります。こうして業務に必要な変更を整理したうえで、全体を一度に作り直すか、必要な部分から順に改修するかを検討できます。
長く使われてきたコードには、業務で必要な条件や処理が組み込まれています。AIは、その内容を調べ、必要な箇所を改修する作業を支援できます。保守や改修の費用が下がると、新しいシステムを作るより、既存の処理を生かして使い続けるほうが有利になる場合もあります。AIによって新しい構成で開発しやすくなると同時に、レガシーシステムも長く使われるようになるでしょう。刷新するかどうかは、技術の新しさに加え、業務に必要な機能が揃っているか、担当者が今後も動作確認や保守を続けられるかを踏まえて判断する必要があります。
まとめ
AIの活用を前提にすると、保守性の高さを判断する基準も変わります。人がコードを読みやすく、修正しやすいことに加え、AIが処理の内容を理解し、必要な箇所を正しく修正できるかも重要になります。さらに、修正後の動作をテストで確かめられる必要があります。AIへの指示から修正結果の検証までを無理なく進められるかが、保守のしやすさを左右するようになるでしょう。
AIでコーディングが楽になったからといって単純に従来のシステムから新しいシステムへの乗り換えが楽になるわけではありません。むしろ、AIが既存システムの必要な部分を直しながら使い続けるという判断を後押しする場面も増えます。
既存システムを使い続ける場合も、新しく開発する場合も、AIが修正したコードを人が確認する必要があります。AIによって開発速度が劇的に向上しても、コードに誤りや意図しない変更がないかを確かめる必要は変わりません。そのため、開発・保守の担当者が十分に習熟した言語を選ぶことも重要です。AIが修正しやすく、担当者もその結果を理解して検証できる技術を選びましょう。
参考文献
Next.js：Project structure and organization
この記事を書いた人
