AI・開発

最適化しようと思ったら、GPT-6.1 Solが来た！コードも運用も見直してみた

AWS CoreとAstraでざっくりチェックした、その次。今度は最適化を意識して見直そうと思っていたら、GPT-6.1 Solが登場しました。Astraと同等という触れ込みなら……！ということで、さっそく試してみることに。

前の話は、AWS CoreをAstraでチェックしてみたノートからどうぞ。今回は、その続きです。

日本時間の2026年9月30日午前2時に始まったOpenAI DevDayで、GPT-6.1 Solが発表されました。さっそくその日に使ってみた、最速！？体験レポートです。モデルの案内はGPT-6.1 Solの公式ページもどうぞ。

最適化しようと思ったら、Solが来た！

AWS Coreを入れて、AstraにAWSまわりをざっくり見てもらった。次は、最適化という観点でも見直してみよう。そう考えていたところに、GPT-6.1 Solが登場しました。

Astraと同等という触れ込みなら……！これは試してみたくなる。そんな流れで、Solにもお願いしてみることにしました。

公式の案内は「Astraに近い性能を、Astraより低いコストで」というもの。どんな仕事でも同じ結果になる、という意味ではありません。今回はモデルの比較実験ではなく、自分たちの開発で使ってみた記録です。

今回見てもらいたかったのは、コード全体の重複や、再利用できそうな処理です。似たものを毎回作っていないか。ライブラリでできることを、必要以上に自作していないか。これからAIが保守するときにも、扱いやすい形になっているか。

機能を足していると、動くことに意識が向きがちです。ちょっと立ち止まって、今あるものを読み返してもらうことにしました。

ここから紹介するのは、Solを試す中で進めた見直しと、継続してきた改善の具体例です。過去の変更まで、全部このモデルだけの成果だったことにはしません。

このHPでは、記事やページを作った後に、検証して、公開して、公開した内容を確認します。その裏側にも、見直せる作業がありました。

公開する内容に変更がないなら、転送やキャッシュ削除は省ける。普段の公開はTOPと変更したページを中心に確認し、全ページの診断は必要なときに行えるようにする。そんな整理を進めました。

全ページを確認することと、キャッシュを削除することも分けました。見たいだけなのに、更新する作業まで動いていたら、ちょっと働きすぎです。

失敗したときに戻すためのバックアップや、公開対象の確認は残しています。それぞれの作業が、今回の変更に本当に必要かを考え直しました。

別のプロジェクトでは、同じ入力を複数の条件で評価していました。判断する条件は違っても、準備に使う計算は共通。そこをそれぞれの評価で繰り返していたんです。

そこで、必要になった共通計算を一度行い、同じ入力を使う評価で再利用する形にしました。

固定した入力で確かめると、時系列の計算は72回から1回、形状の計算は39回から1回に。その条件で、変更前後の予測出力が同じことも確認できました。

これは「72倍速になりました！」という数字ではありません。数えたのは計算回数で、本番の時間や費用の削減率はまだ測っていません。数字が派手だと、つい言いたくなるんですけどね。

約170秒が10秒程度に！？

あ、言ってしまいました。

これは、別プロジェクトのリアルタイム処理で、主にLambdaで行っている一連の処理を改善した途中経過です。今もさらに改善を進めていて、早い時は5秒程度になっています。

再利用したデータが後の処理で書き換わり、別の評価へ影響しないかも確認しています。同じ結果を保てるところまで確かめて、最適化です。

見直しを進める中で、もう一つ気になりました。作業時間が長い。サブエージェントのレビュー、過剰にやっていない……？

確認すると、ある変更では最初のレビューに加え、修正後の確認が繰り返され、変更した版ごとに全体の検証も走っていました。有効な指摘はあったものの、会社HPとしては工程が重くなっていました。

そこで、通常のHP変更は担当AIの対象確認と必要な自動検証で進める形へ。公開ツールだけを変えたら、その処理に関係するテストを選ぶ。修正したら指摘箇所を確認する。同じ確認を一律に繰り返さないように整理しました。

秘密や個人情報の新たな公開、権限の拡大、元に戻せない操作などは、引き続き別の境界として扱っています。

コードの無駄を見てもらったら、AIの仕事の進め方にも見直すところがあった。最適化する作業も、最適化が必要でした。

HPでは、キャッシュ削除の完了を確認する間隔も短くしました。もう完了しているのに次の確認まで待っているなら、その時間を減らせるかもしれません。

ところが、変更後の記録ではキャッシュ削除の処理全体は前回と同じ24秒。この一回では、明確な短縮は見えませんでした。確認間隔を変えても、配信サービス自体の反映が速くなるわけではないんですね。

計算回数が減ったこと、公開処理を省ける条件を作れたこと、実際の所要時間が短くなったこと。それぞれ別に見ていく必要があります。

変えられたことは残しつつ、効果は測れた分だけ。いい感じの話に盛りすぎず、次に確かめる材料にしていきます。

今回は、新しい機能を作る以外にも、新しいモデルを試す使い方がありました。今あるコードや、いつもの運用を読み返してもらうことです。

人間が気になる点と任せる範囲を伝え、AIがコードや記録を調べて改善を進める。途中で「そこまで確認が必要？」と問い直し、進め方も調整する。そんな往復になりました。

AstraとSolを同じ条件で競わせたわけではないので、どちらが優れているかという結論は出していません。