株式会社CINC 開発本部(旧:開発部) エンジニアブログ

開発部→開発本部!!ビッグデータ取得/分析・自然言語処理・人工知能(AI)を用いた開発を軸に、マーケティングソリューションの開発や、DX推進を行っている、株式会社CINCの開発本部です。

【新モデル使ってみた】GPT-5でコードを書いてみた個人的な感想と効果的な運用の考察

【新モデル使ってみた】GPT-5でコードを書いてみた個人的な感想と効果的な運用の考察 こんにちは、株式会社CINC開発本部です。

最近話題のGPT-5、皆さんはもう試されましたか?「これは使える!」「作業が格段に楽になった」と実感する一方で、「あれ?思ったより…」という場面もあるのではないでしょうか。 今回は、実際にGPT-5を使ってコーディングしてみた体験談として、良かった点・困った点、そして最終的に落ち着いた使い方について、開発現場の声として共有させていただければと思います。

GPT-5そもそも変わったところは

GPT‑5 は 2 つのモデルを搭載しています。ほとんどの質問に回答する、高性能かつ高速度のハイスループットモデルと、より難しい問題に対応する高度なリーズニングモデル(GPT‑5 思考)です。また、会話のタイプや複雑さ、必要なツール、あるいは「慎重に考えて」といったユーザーの明確な意思に基づき、リアルタイムルーターがどのモデルを使用するかをすばやく判断します。ルーターは、ユーザーによる手動切り替え、優先設定、測定された正確性など、実際のシグナルを基に継続的に学習し、継続的に進化しています。いずれかのモデルで利用上限に達した場合は、推論機能を備えたモデルの mini バージョンが残りのクエリに対応します。近いうちに、これらの機能をすべて 1 つのモデルに統合する予定ですが、ユーザー体験は現時点ですでに一貫性のあるものに感じられるはずです。

openai.com

変更点、色々あるとは思いますがメインは「ルーターによるモデルの使い分け」ではないでしょうか

いい側面としては「選ばなくて良い」
悪い面としては「選べない」モデルになってます

この部分も見ていきます。

検証してみました:使用環境とモデルの種類

使用した開発環境

今回の検証では以下の環境で試してみました:

  • 開発ツール:Cursor(普段はCopilotメイン、検証目的で発行してます)

  • 開発言語・フレームワークPython + Streamlit での開発

利用可能なモデル群がいっぱい!

実際にCursorで確認してみると、以下のようなモデルが選択できます:

実際に使ってみた率直な感想

よかったところ

GPT-5-highの安定感
遅いながらも精度はそんなに悪くない印象でした。ゆっくりで待ちが多くなるものの、そこそこ任せられるので使い心地はどっちかというとClaude Codeの方が近いイメージです。 chatの設定次第ですが、除外コマンドを設定しつつauto runで使ってます、このモデルの用途だとこっちかなという印象です。

良くないところ

思考過程の不透明性
多分考えてるんだけど思考が文字で出てこない部分が多いのが気になりました。推論モデルで思考過程が隠されて見えないのは、GPT-4.1のチェーン思考が見える状況と対照的で、チューニングが若干しにくいですね。

推論偏重の課題
基本、推論にしかなってない気がします。(プログラムはほとんど、推論になってるのかな? 勿論、たまに早い時もあります)

GPT-5はリアルタイムルーターでモデルを切り替えているはずですが、推論処理に偏っていて応答性に欠ける印象を受けました。その影響で基本時間がかかってます。

GPT-4.1を使っているので、fastモデルでも遅く感じてしまいます。これは単純に処理時間の問題だけでなく、開発のリズムにも影響する部分でした。並走して開発するには今のところ微妙ですね。

リアルタイムルーターどう?

個人的には今の精度ならなし

あまりにも推論により過ぎているイメージですね

別用途を仮定すればまたちょっと印象変わるのかもしれないですが...

この方式の最大のデメリットはやって直す方式を進めにくいこと

この形にすると「精度60%でいいから曖昧な命令でも速度重視で」ができないんですよね

レビューをしながらちょっとづつ形を作っていくタイプにはしんどい仕様ではないでしょうか

最終的に落ち着いた使い方:Autoモードでの使い分け戦略

色々やってみましたが、最終的に安定したのは以下の運用でした。

実際の運用ルール:役割別モデル選定表

GPT-4.1をメインにしつつ、シニア的な立ち位置でGPT-5-highを利用という方針のもと、実際に以下のような運用ルールを策定して使っています(cursorに行動指針としてルールに記載):

開発の役割・作業内容 推奨モデル 理由
ソフトウェアエンジニア(Junior〜Mid) GPT-4.1 基本コード例の提示や軽い修正など、スピードとコストのバランスが良い
ソフトウェアエンジニア(Senior) GPT-5 High 複雑な技術課題や設計レビューで最大限の推論能力を活用
ソフトウェアアーキテクト GPT-5 High 大規模構成設計や将来拡張性の検討など、深い推論と長期的視点が必要

実際の運用ルール:作業ベース

また作業ベースでもモデルを指定してます cursorのautoモードがちゃんと切り替えてくれているのか不明ですが、 今のところ悪くないです。 ただ速度は明らかに早くなりました。

1. タスク名決定 (gpt-4.1)
    - 【ステップ1】タスク名決定を実行します
2. ./docs/task/{タスク名}/現状把握.mdを作成 (gpt-4.1)
    - 【ステップ2】現状把握.mdの作成を実行します
3. 現状を調査 (gpt-4.1)
    - 【ステップ3】現状調査を実行します
4. 現状を確認して追加調査指示 (gpt-5-high)
    - 【ステップ4】追加調査指示を実行します
5. 追加調査 (gpt-4.1)
    - 【ステップ5】追加調査を実行します
6. ヒアリング.mdに質問事項を記載 (gpt-4.1)
    - 【ステップ6】ヒアリング.mdへの質問事項記載を実行します
7. (ユーザー操作) ./docs/task/{タスク名}/ヒアリング.mdを回答 (gpt-4.1)
    - 【ステップ7】ヒアリング.mdへの回答を実行します
8. ./docs/task/{タスク名}/task.mdを作成 (gpt-4.1)
    - 【ステップ8】task.mdの作成を実行します
9. 解決すべき課題をバックログレベル、ストーリーレベル、タスクレベルで記載 (gpt-5-high)
    - 【ステップ9】課題の記載(バックログ・ストーリー・タスク)を実行します
10. ./docs/task/{タスク名}/設計_{ストーリー名}.mdをストーリー分作成 (gpt-5-high)
    - 【ステップ10】設計_{ストーリー名}.mdの作成を実行します
    - 難易度の高いタスクは(gpt-5-high)を使うように明言すること
    - 簡単な実装は(gpt-4.1)を使わせること
11. 実装  
    - 【ステップ11】実装を実行します
    - デフォルト: (gpt-4.1)  
    - 難易度:高のタスク (gpt-5-high)
12. 完了したストーリーの設計には【実装ずみ】を先頭につける (gpt-4.1)
    - 【ステップ12】設計ファイルに【実装ずみ】を付与します
13. 動作確認.mdを作成 (gpt-4.1)
    - 【ステップ13】動作確認.mdの作成を実行します
14. (ユーザー確認) 動作確認 
    - 【ステップ14】動作確認を実行します
15. あれば修正改善を行う (gpt-4.1)
    - 【ステップ15】修正・改善を実行します

基本的な判断ルール

  1. 各作業フェーズで、難易度の高いタスクや設計・要件整理は「GPT-5 High」を明言して使用
  2. 簡単な実装やドキュメント作成は「GPT-4.1」を明言して使用
  3. どのモデルを使うか迷った場合は、まず「GPT-4.1」で試し、難しければ「GPT-5 High」にエスカレーション

役割分担の考え方

実際の開発フローでは:

  • メイン作業:GPT-4.1で高速処理、後からの軌道修正や修正対応がしやすい

  • 上流設計・レビュー・アドバイス:GPT-5-highで時間をかけた高精度処理

この使い分けにより、速度と精度のバランスを取ることができるようになりました。

GPT-5を使ってみてGPT-4.1を再評価:実はプログラミングに適したモデルかも

使い比べてみて気づいたのは、GPT-4.1がかなり良くなっていて、プログラミングに向いているということでした。

速度と精度のバランスが秀逸

  • 適度な精度で早い:そこそこの精度を保ちながら高速処理が可能
  • 後での切り返しがきく:早いので、切り戻し含めても時間的には安くつくことも、GPT-4.1の方が個人的には好み

精度 vs 速度のトレードオフ

時間かかっても完全なバイブコーディングを目指すなら単品でGPT-5 Highを使うのもありかもしれません

ただ個人的には:

  • 日常的な開発作業:GPT-4.1の高速性を活用して切り返しを重視
  • 完璧なコードが必要な場面:GPT-5-highで時間をかけた単品利用

この使い分けが現実的だと感じました。

推論モデルがコーディングに向いているのだろうか

もちろん状況によりますが、私の感覚では、推論モデルは大規模なリポジトリにおいて、速さ・情報量・技術力を含めた総合力で見ると、シニアエンジニアの下位互換に過ぎないと思います。

これはモデルだけの問題ではなく、そもそもリポジトリ内にPJの背景だったり、メンバーの判断軸だったり、価値観だったりまで乗せきれないので、高い精度の判断をする材料が揃えきれないからというのもあります。

逆にGPT-4.1のような中身だとアウトプットの速度だけであれば人に勝ってると思うので、精度が悪ければ補足をもらって修正すればいいです。

個人的にはこっちの方がいいんじゃないかな...とは思ってます。

これはコーディングに限った話で、タスク難易度が上がってくると逆にGPT-4.1だとどこまで行っても微妙になると思うので、 そこのタスクにはGPT-5-highはいい選択肢なのではないでしょうか

GPT-5のリアルタイムルーターがここらへんの使い分けをちゃんと精度高くできるようになればこのようなことも考えなくて良くなるのかもしれないですが

実践的な運用のコツ

実際に運用してみて分かったコツをいくつか共有します:

モデル選定の判断基準

  1. タスクの複雑度:単純な実装 → GPT-4.1、複雑な設計 → GPT-5 High
  2. 時間の制約:急ぎの場合 → GPT-4.1、時間をかけられる場合 → GPT-5 High
  3. 精度の要求レベル:そこそこで良い → GPT-4.1、完璧が必要 → GPT-5 High

エスカレーションの流れ

タスク発生
    ↓
まずGPT-4.1で試行
    ↓
満足いく結果?
    Yes → 完了
    No → GPT-5 Highにエスカレーション
    ↓
高精度で処理
    ↓
完了

基本的にはリアルタイムルーターのやりたいことに近い使い分けですが、 一般的にはコーディングそのものが複雑なタスクなのかもしれません。

まとめ:高度なAIモデルとの賢い付き合い方

GPT-5も、その実装を支援してくれる開発ツールも、非常にパワフルで私たちの開発作業を助けてくれる「頼れるパートナー」です。

しかし、そのパートナーも時には意図しない挙動を示すことがあります。だからこそ、その特性をよく理解し、私たちが適切にコントロールすることが重要になってきます。

GPT-5が出たものの、まだGPT-4.1はまだ優秀な択として存在しているのでそれも踏まえた運用設計をしていただけるといいのですね。

またリアルタイムルーターの精度次第ではここの状況も変わってくると思うので、そこも注視していきたいです。