AIとの"いい感じ"な付き合い方

こんにちは！プロダクト開発部のhartoです！

Newbeesには半年ほど前に入社したばかりなのですが、新しい環境に戸惑いながらも「マリッシュ」という恋活・婚活サービスでバックエンドエンジニアをしています。
エンジニア歴は約7年ほどで、前職以前でも基本的には9割方バックエンドを担当してきました。

バックエンドと一口に言っても、クラウドやネットワークなどのインフラ部分から、設計・実装・テストのような開発部分まで多岐にわたるかと思います。 私はそのなかでも設計・実装などを担当することが比較的多かったため、本記事のテーマでもある”AI”の台頭によって「仕事がなくなるのではないか？」と世間で騒がれている職種の筆頭を担ってきました。
純粋に仕事を奪ってくれるのであればこちらとしても嬉しい限りなのですが、今までのプログラミングや周辺技術の歴史を見るに、「仕事は形を変えて残り続けてしまうのではないか？」というのが私の見解です。

AIの利用に対して気が乗らなくとも、世間がその方向に進んでしまっている以上、一定程度のキャッチアップをしないと形を変えたあとの仕事ができなくなってしまうのも事実です。 そんな怠惰な自身と向き合うためにも、私なりのAIとの付き合い方を書いていこうと思います。

昨今のAI事情

さて、みなさんは昨今のAI事情にどれほど付いていけていますか？

私が新卒だった当時はOpenAIのGPT-2が出たばかりの時期で、世間的にもここまでの発展を予見できていた人は極々少数だったように思います。
それが今では若い世代を中心に多くの人が、仕事ではコーディングや資料作成をお願いし、プライベートでも悩み相談や愚痴を話す相手として活用しています。
しかし、その便利さの一方で急速なテクノロジーの発達によるAI関連情報の過剰摂取や圧から、"AI疲れ"のような状態を引き起こしている人も多いのではないでしょうか？

個人的興味からAIを学ぶことは非常に良いことです。 しかし、私のように「周りについていかないと……」というモチベーションで興味もなく情報を追っていくには、昨今のAI事情において中々苦しいと感じてしまうことも多いのではないかと思います。
一方で、AIの情報の一切を遮断して捨て置けばいいかというと、それはそれでエンジニアとしてのキャリアが許さないでしょう。 そんな中、我々に求められているのは、追いすぎず知らなさすぎずの"いい感じ"にAIと付き合っていくことなのではないかと考えています。

"いい感じ"とはどんな感じか

私の周囲、特にエンジニアを見渡してみると、大抵のエンジニアは私より意欲的に情報収集をおこなっている人の方が多い印象です。 プライベートでのエンジニア同士の雑談ではAIを主軸とした会話が展開されることも多いですし、社内では会社が費用を出しているというのを良いことにClaudeCodeで多量のトークン消費に対し快感さえ覚える様をも見かけます。
もし、自分が同じペースでAIの情報に触れ続けたら間違いなくAIのことを嫌いになり、アレルギー反応による蕁麻疹が出てしまうかもしれません。
しかし、その人たちの話を聞く限り、特にAI疲れのようなこともなく、あたかもそれが普通のことかのように情報を摂取しています。

ただし、これはあくまで自分の周りのエンジニアを対象とした場合に限った話で、それなりに世間を広く見渡せばAIのアウトプットを盲信し一次情報と同等の信頼性を誤認してしまう人や、私以上にAI利用が消極的な人も多く散見され、むしろ自分はAIを使いこなせている方なのではという錯覚を覚えることもあります。

このAIに対する温度感は人によって違い、AI関連の情報を追うのが好きで趣味のように楽しい人もいれば、業務上必要だから最低限触る人もいます。
以降ではどちらが正しいという話ではなく、個々人のAIへの投資対効果が釣り合っている状態を"いい感じ"とし、私が実際におこなっているその"いい感じ"を参考例として紹介したいと思います。

"いい感じ"にChatGPTを使う

章題から早速違うことを書いてしまっているのですが、私は現在ChatGPTを使用しておらず、OpenAI Platformを利用しています。 OpenAI Platformと聞くとAPIをcurlなどで直接叩いているかのように思われるかもしれませんが、そういうわけでもなくOpenAIが提供している画面上（以下、PlayGroundといいます）からAPIの呼び出しが可能なWebツールのようなもの使用しています。

GUI形式、それもChatGPTに似たチャット形式なのであれば「なぜChatGPTではなくわざわざPlay Groundを？」と思われそうですが、私にとって"いい感じ"に使うためにはこちらの方が使い勝手がよく、いくつかの利点がありました。 その違いに着目しつつ、使い勝手について書いていこうと思います。

同じところ

まず、先述した通りチャット形式のUIというところは同じです。 実際の画面の画像を貼りましたが、下部の入力欄ではGPTへの質問などを入力し、その回答が上部に表示されます。 そのため、ChatGPTを含む多くのチャットAIを利用してる人であれば特に使用感を変えることなく使い始めることが可能です。
また、使用できるモデルも基本的には同じものが揃っています。 画面の左上に"Model"の選択ができるセレクトボックスがあり、画像のように多くのモデルが提供されています。GPT-5.4はProも含め当然使用可能ですし、今更使う人がいるかは疑問ですがGPT-3.5のような古いモデルも選択できます。

通常のGPTモデルはChatGPTと比べてやや硬めの文体で返答をおこないますが、ChatGPT特有のフレンドリーな文体や回答を求めるのであればGPT-5.x-chat 系モデルを使用することで同じような感覚で接してくれます。

▼GPT-5.4の返答

▼GPT-5.4-chatの返答

違うところや利点

"同じところ"を見るにChatGPTとなんら変わりないような印象ですが、ここからが本題です。

料金体系の違い

まず、ChatGPTとの1番の違いは料金体系にあります。

ChatGPTはご存知のとおり、月額定額制を採用しています。
この記事の執筆時点（2026年3月時点）でChatGPTでは、制限が多い代わりに利用料金の掛からない"無料版"から、すべての機能を使用可能で月3万円の費用を要する"Pro"までの4種類を個人向けのプランとして提供しています。
定額制はどれだけ使用しても一定の金額しか請求されないという安心感もあり、昔は私もChatGPTの有料プランに加入していました。
しかし、GPTモデルのなかで現在もっともベンチマークが高いGPT-5.4やオンライン情報を参照可能なDeep Researchは無料版でも使用できますが、実用性を体感できる程度の使用となると無料版では物足りないこともあります。 また、ある月だけ多用する必要があって上位プランに加入したものの、平常時はそこまで利用せず、また下位プランへの切り替えも忘れてしまい意味のない課金を続けてしまうことも発生しがちです。

では、先ほどのPlayGroundはどうかというと、こちらは従量課金での利用となります。
料金はAPIを叩くときに発生する金額と同じくModelとトークンによって変わるため、使えば使うほどコストも増えますが、逆に一切使用しないのであれば掛かる金額も0です。
そのため、GPT-5.4を制限なく利用したいがAIを多用するわけでもないので月額料金だと無駄が出そう……という場合、こちらを利用している方が断然安く済むことが多いです。

送信したチャットの編集可能範囲

世間では「プロンプトはこうすると精度が上がる」「こういうテンプレが便利」といったプラクティスを紹介するSNSアカウントや記事が大量に存在し、各々が独創性に溢れた見解を説いています。もちろん、そういう知見自体は役に立つことも多いです。
しかし、AI怠惰な人間である私はn-shot？CoT？と言われてもさっぱりですし、日々変わりゆく自然言語を用いた擬似プログラミングのようなことをおこなう事態を可能な限り避けたいのです。
この点でPlayGroundがありがたいのは、ChatGPTよりもチャット履歴の編集の幅が広い点にあります。
ChatGPTでは、一度間違った前提を伝えてしまいあとから情報を訂正したいときには、それを訂正するメッセージを合わせて送るか、訂正したい地点まで編集によってやり取りを戻す必要があり、メッセージ送信前にプロンプトを精査する必要が多少なりとも生じます。
しかし、PlayGroundでは一連のやり取りのどこであってもメッセージを削除したり、一度送信したメッセージを一部分だけ編集して改めて回答をしてもらうこともできます。

例えば、最初にいくつかの前提条件を箇条書きで渡した上で、仕様書をまとめてもらう作業を任せたとします。
何度かのやり取りをおこない、ある程度は仕様書が形になった段階で、一番最初に提示した条件が一部間違っていたことが発覚します。
そんなとき、PlayGroundならば一番最初のチャットを編集することで箇条書きの一部を消して無かったことが可能です。 便利ですね。

▼最初の△△△を消したい場合は、チャット右側の鉛筆マークから該当箇所のみを編集する事が可能です

結果として、プロンプト一発で当てるための作法を身につけるよりも、出力を見ながら前提を調整する方に寄せられるため、私にとっては“いい感じ”でした。

また、軽微なことであればそもそも文章にする必要もないのではないかと最近は思っています。
かつて、我々にとって情報を得る手段といえば、まず挙がるのは検索エンジンでした。
そのため、非AIネイティブ世代だとしても"単語をスペース区切りにして投げる"ことは少なくともできるはずです。
LLMは細かいことを無視すれば"与えられた文章から統計的にそれらしい文章を生成する"ものなので、知りたいことがあまり複雑でない場合、必ずしも綺麗な文章で質問する必要はないのです。

そこまで省略すると間違った意図で読み取られてしまう？ そんなときはメッセージ履歴を編集して、追加ワードを入れた上でもう一度聞きましょう。

"いい感じ"にGitHub Copilotを使う

一般的にCopilotのような生成系のAIを前にした人がよく陥りがちな思考パターンとして「なんかTab押してたら動くものができた！最高！」というものがあります。
この思考の厄介なところは一見すると動いており、かつ実装スピードも上がったと感じてしまい、成功体験だと錯覚してしまうことにあります。
確かにその場では早く実装できたかのように錯覚しますが、長期的に見ると改修コストは確実に上がり、改修するなら実装し直した方が早いのではという疑念が生まれることさえ少なくありません。
最近では"理解負債"というワードも見聞きする機会が増えましたが、我々はこれに何としても食い下がらねばなりません。

実装ガチャをやめる

これから実装したいところにカーソルを合わせ、出てきたコードが動けばそれを確定。動かなければまた別のコードを出力させて満足感を得る。 まさにガチャという単語に遜色ないことを日々おこなっている人は決して少なくないのではないでしょうか？
ガチャというのは言い得て妙で、人間の脳とは都合よくガチャで当たったときのことは鮮明に覚えている一方で、外れたときのことはすぐに無かったことにしてしまいます。
この小さくも大量の成功体験が積み重なり、実装作業を"ガチャを引く"ことに変貌させてしまいます。
なので、もしもこのガチャを引くというのに思い当たることがあるならば、まずはそれをやめましょう。

コメントでちょうどいい指示を出す

Copilotにコメントで指示を出すときは、抽象的にしすぎず、具体的にしすぎずを意識しています。
非常に単純化した例ですが、例えば下記のような配列からnameだけを取り出した別の配列を作りたいとします。

$rows = [
    ['id' => 1, 'name' => 'hoge', 'age' => 29],
    ['id' => 2, 'name' => 'fuga', 'age' => 29],
    ['id' => 3, 'name' => 'foo', 'age' => 29],
];$rows = [
    ['id' => 1, 'name' => 'hoge', 'age' => 29],
    ['id' => 2, 'name' => 'fuga', 'age' => 29],
    ['id' => 3, 'name' => 'foo', 'age' => 29],
];

ここで「配列を加工する」のような抽象的すぎるコメントを記載しても「何をどうしたいのか」が伝わらず、的外れな補完が出やすいのは当然ですが、逆に下記のような具体的すぎるコメントにしてしまうと、それが縛りになってしまい自分が思いついていなかった別解が出にくいです。

// for文で回して $rows[$i]['name'] を $names に入れる
$names = [];
for ($i = 0; $i < count($rows); $i++) {
    $names[] = $rows[$i]['name'];
}// for文で回して $rows[$i]['name'] を $names に入れる
$names = [];
for ($i = 0; $i < count($rows); $i++) {
    $names[] = $rows[$i]['name'];
}

なので「何をしたいか（What）」と「最低限の条件」だけを書いて、手段（How）は固定しないようにするとちょうどいい回答が出やすいように思います。

// $rows から name だけを取り出す
$names = array_column($rows, 'name');// $rows から name だけを取り出す
$names = array_column($rows, 'name');

このくらいの粒度であれば、Copilotがforeachで書く案やarray_column関数を使用して短く済ませる案も出しやすくなって、実装ガチャではなく「候補から選ぶ」に寄せられるのでちょうどいいです。

"理解負債"を封じ込める

ここまで書いたは良いものの、現実問題として時間や納期は理解負債を理由に待ってはくれないですし、人の集中力にも限界があるため、AIを使う以上は完全にゼロにすることは非常に難しいと思います。
そのため、理解負債は出てしまうものだという割り切りも一定程度は必要だと考えています。

例えば、テストによって入出力のパターンが網羅され他への依存性も少ない関数の場合は、内部実装をリファクタリングするコストがそこまで大きくなることもなく、予期せぬ不具合が起きそうになっても未然に防ぐことが可能です。 そのような小さいまとまりであれば、むしろ負債を負ってでも開発スピードを上げて、他の負債が生まれないようにするほうが有意義に思えます。 逆に、テストもなく多くの機能から参照され例外的な処理も多く内包しているような関数に変更を加える場合に、さらに負債を積み重ねてしまうと確実に不具合を起こします。

そのため「この状況では理解を先送りにしても問題ないか？」を常に考慮して向き合うことが、今のコード生成時代における実装者の役割なのではないかと思います。

最後に

現時点で、自身のスキル次第ではAI関連の情報をすべて避けながらプログラムを組んだりシステムを作ることも、まだまだ可能な時期ではあると思います。
しかし、かつて高級なプログラミング言語が発明されアセンブリ言語での仕事が淘汰されたときのように、いつかAIの使用知識が必須になる未来は確定的と言ってもいいでしょう。
そんな来るべきときが来たときへの備えは一朝一夕で習得できるものではないことも理解しているため、怠惰ながらも自分に合った付き合い方を日々模索しています。

AIの情報が日々アップデートされるように、“いい感じ”というのも固定化する必要はありません。
日々登場する新しい情報を怖がらず、可能な範囲で柔軟に自分の中へ落とし込み、少しで良いので実践し、各々の"いい感じ"を少しでも前に進められることができれば幸いです。