menu
デジタルファームは、札幌・東京・大阪を拠点に、Web戦略の立案からシステム開発、ホームページ制作、SNS運用、運用改善まで一貫支援。Web活用によるビジネス課題解決をサポートします。

AIと書くコードを、人にもAIにもやさしく保つために

シェア
ツイート
シェア
ブックマーク
タイトルとURLをコピー
AIと書くコードを、人にもAIにもやさしく保つために

最終更新日:2026/08/08   公開日:2026/06/05

はじめに

弊社では、AI を当たり前のように開発に利用しています。 しかし、私たちは AI が出力したものをそのまま成果物とすることは考えていません。出力が「意図したとおりに動いているか」を確認して、初めてそれが成果物であるという考えでシステムを開発しています。そして、その確認をできるだけ安く済ませるために、私たちは明示的で追いやすいコードを選ぶようにしています。

本記事は、その理由を弊社なりの考えとして共有するものです。あくまで一つの立場として参考にして頂ければと考えています。

AI が肩代わりするのは「誰が書くか」だけ

AI の登場で大きく変わったのはコードを「誰が書くか」という部分です。これまで人が一文字ずつ書いていた定型的なコードは、かなりの精度でAIに生成を任せられるようになりました。

一方で、変わっていないこともあります。「このコードは意図したとおり(仕様通り)に動く」と保証する責任は、私たちの考えでは依然として人の側に残っています。 お客様に納品するのは私たちであり、不具合の責任を負うのも私たちです。 プログラムなどを書く作業は移譲できても、責任は移譲できない。 ここは、AIがどれだけ賢くなっても当面は変わらない部分ではないかと感じています。

この非対称性は、開発の中で時間がかかる場所を静かに移動させました。かつては「コードを書く」ことが時間がかかる大きなコストでした。しかし、今は AI の活用によって書くコストが下がっています。 そのため、相対的に「挙動を確認する」ことに時間が必要になりつつあります。

私たちは AI の出力したコードを過信しません。

AI は非常に優秀なパートナーであり、多くの可能性を秘めています。 しかしその性質上、間違えた出力や利用者が意図していない出力をすることがあります。 そのため、きちんと確認をします。 だからこそ、生成物の確認のしやすさが開発全体の質を左右すると考えているのです。

確認のしやすさは、コードの何で決まるか

コードの確認作業とは、本質的には「実際の挙動と、意図した挙動が一致しているかを確かめる」ことです。この確認にかかる手間は、主に以下の3つのポイントで大きく変わります。

  • 処理があちこちに散らばっていないか(見通しの良さ)
    ある機能について調べたいとき、ソースコードの該当箇所を見るだけでパッと動きが分かるなら、確認作業はとてもスムーズです。検索(grep)もかけやすく、定義へのジャンプもすんなり機能するため、AIも根拠のある的確な答えを返してくれます。 反対に、処理がいろいろな場所に分散していたり、裏側の仕組みまで追わないと実際の動きが掴めなかったりすると、確認にかかる負担は一気に跳ね上がります。
  • 書き方が予測可能か(一貫性)
    AIは、学習した膨大なパターンの蓄積に沿ってコードを処理します。ルールが統一された素直なコードであれば、AIの予測は外れにくく、人間のレビュアーにとっても「だいたいこう書かれているはず」と当たりをつけることができます。 場所によって書き方がばらばらだと、AIも人間も毎回構造を推測し直す必要があり、確認の負担が大きく増大します。
  • 暗黙のルールに頼らず、ストレートに書かれているか(明示性)
    「短いコード」が常に「分かりやすいコード」とは限りません。記述量を減らすための便利な仕組みや過度な抽象化は、その独自のルールを知らない限り、人間にとってもAIにとっても何が起きているのかを追いにくくします。 暗黙のルールに頼らず、処理がストレートに明示されている方が、人間にとってメンテナンスしやすいのはもちろん、AIにとっても余計な推測の余地が減るため、結果として確認の精度がより安定すると考えています。

この3つのポイントは、決して特別なものではありません。「人間が読みやすいコード」と「AIが正確に扱えるコード」は、おおむね同じ方向を向いているというのが、私たちの見立てです。

実際にあった例:管理画面を自前で書いた話

具体的な場面を一つ挙げます。ある案件で、管理画面の構築に Backpack for Laravel を使っていました。宣言を少し書くだけで画面が組み上がる、よくできた仕組みです。

しかし、その案件ではお客様のご要望がライブラリが標準で想定する形から外れることがたびたびありました。そうした要望に応えようとすると、ライブラリの内部の挙動に手を入れる、いわゆるハックのような対応が必要になります。そうなった瞬間、その処理は AI に書かせても正確になりにくく、レビューする側もコードの表面を読むだけでは何が起きるか追いきれなくなりました。

その経験をもとに、最初から要望が標準的な形に収まらないと見込まれた別のプロジェクトでは、画面の見た目は AdminLTE のような土台を借り、アプリケーションの挙動は Laravel のコントローラーに素直に書く、という形で管理画面を開発してみました。 すると、結果として、AIによる記述の精度が上がり、何よりレビューの際に「意図したとおりか」を自分たちのコードを読むだけで確認できるようになりました。

なお、強い規約を持つ宣言的なフレームワークやライブラリの価値を否定する意図はまったくありません。これらは、想定された使い方の範囲では開発を大きく加速してくれますし、大人数で一貫性を保つうえでも有効です。

ただ、弊社が手がける案件では、自分たちの思想やお客様のご要望にぴたりとはまるフレームワークが見つかることはむしろ少なく、より汎用的なフレームワーク(Laravel など)を土台にするほうが性に合っている、というのが正確なところかもしれません。 

おわりに

弊社にとって、AIをうまく使うということは、AIの出力を確認しやすい土俵にきちんと乗せることだと考えています。明示的で追いやすいコードは、書き手であるAIにとっても、それを確認する私たち人間にとってもやさしく、結果として価値のある成果物につながる——これが現時点での私たちの実感です。

だからこそ『コードを書くのはAIに任せても、動くことの保証は私たちの仕事』だと考えています。 

また、今回ご紹介した「管理画面を自前で書く」という選択は、以前なら車輪の再発明として避けていたかもしれません。それをあえて選べた背景には、AIの登場によって「車輪の再発明を避ける」という長年の判断基準そのものが揺らぎ始めている、という感覚があります。 なぜそう言えるのかは、また別の記事で書ければと思います。