AI 活用：開発・設計・コンテンツ制作

2023 年に Gemini を使い始め、その後は年間契約で継続して利用しています。Notion AI も使い続けています。2026 年には Codex と ChatGPT が日々の開発に加わり、普段の接続経路が制限される場合は Claude Code に切り替えることもあります。

これらのツールと取り組む仕事は、コードの実装、システム設計の検討、そして Agent を使った創業者の発信支援や動画の口述原稿づくりへと広がりました。

使い続けて実感する変化があります。以前は「自分に実装できるだろうか」で止まっていたアイデアを、今はまず動かしてみて、どう作るべきか、どこまで作る価値があるかを考えやすくなりました。

1. 継続して使い、仕事に応じて選ぶ

継続契約によって、日常の仕事や繰り返す修正の中でツールの振る舞いを観察できます。一度すばらしい回答が出たことだけでは、長く使えるかは分かりません。使える成果まで一緒に進められるかを重視しています。

現在よく使うのは、私の ChatGPT 環境での 6 Sol、Claude Code での 5.5 Haiku、そして Gemini 3.1 Pro です。バージョンは変わっていきます。ここでは個人的な使用感と選び方を記録します。

これは自分の仕事と好みに基づく選択であり、条件を揃えたモデル評価ではありません。「人らしい文章」という感覚にも、語り口への好み、渡した資料や修正指示が影響します。

ある一か月の実際の利用記録

以下は、私が利用する AI 接続プラットフォームの一つにおける、2026 年 9 月の統計です。リクエストは 45,118 回、総 Token 数は約 49.5 億、画面に表示された実際の利用料金は約 674.23 米ドルでした。AI を日常の仕事で継続して使っていた時期の記録です。

総 Token 数には約 42.7 億のキャッシュ Token が含まれ、すべてが新しく生成された内容を意味するわけではありません。料金も、このプラットフォームの課金基準によるものです。この画像は一つの接続プラットフォームの記録であり、すべての AI ツールを合計した利用量ではありません。

繰り返し使うことで、多くの実務の中でツールを観察できます。ただし、成果の価値は、コードが検証を通るか、設計を実装できるか、原稿を実際に使えるかによって判断します。

2. GPT によって設計へ意識を向けやすくなった

以前は機能を考えると、まず関連技術を知っているか、実装する時間があるかを判断していました。実装コストが、検討する前にアイデアの範囲を狭めることもありました。

Codex と ChatGPT を取り入れると、着手しやすくなりました。不慣れなフレームワーク、初めて作る操作、複数モジュールにまたがる変更も、分解して少しずつ進められます。

その感覚は率直です。どんな機能でも試せそうで、世界が手の届くところへ広がったような高揚感さえあります。

私はこれを、挑戦できる範囲が広がった感覚だと捉えています。コードができた後も、業務ルールは成立するか、責務は明確か、状態をどこへ置くか、失敗からどう復旧するか、次の変更がどこへ影響するかという判断は残ります。

その分、設計と取捨選択に力を使えます。コード生成が速くなるほど、解決する問題、守る制約、受け入れられる結果を明確にすることが重要になります。

AI によって案を試しやすくなり、同時に設計と受け入れ確認に継続して関わる必要性も見えるようになりました。最初の一回の指示だけでは完結しません。

3. 実際の修正：AI と MQ 消費処理のトランザクション境界を整理する

RegenBio のレポートシステムを調査した際、具体的な問題に直面しました。承認処理を RocketMQ で非同期に進めていましたが、コンシューマーが例外を投げても、DB の変更が期待どおりにロールバックされませんでした。

対象はコンシューマー側のローカル DB トランザクションであり、RocketMQ のトランザクションメッセージ機構自体ではありません。再配信と DB のロールバックは異なる仕組みの責務です。例外によって再配信されても、先に行った DB 更新が取り消されたとは限りません。

現象から呼び出し経路をたどる

まず AI にメッセージテンプレートと承認リスナーのコードを読ませ、対応案の分析を依頼しました。送信側には既にトランザクションのコミット後にメッセージを送る設計があり、受信側では共通のリスナー入口から業務の消費メソッドを直接呼んでいる、と二つの境界を整理しました。

承認リスナーには @Transactional がありましたが、継承した入口と内部呼び出しによって、業務処理が実際に Spring のトランザクションプロキシを通るかを確認する必要がありました。AI は共通入口での明示的なトランザクション管理を提案し、失敗状態の記録、リトライ、通知送信には個別に整理すべき点があると指摘しました。

「例外を投げたのに戻らない」という現象を、確認可能な呼び出し経路、トランザクション境界、副作用に分解することに価値がありました。アノテーションがあるだけで有効だとは判断できません。

私の判断：共通能力を先に整え、業務変更を限定する

AI は当初、承認業務サービスの分離、失敗時の意味づけ、通知時点の変更を含む広い修正案を示しました。私は一度にすべてを進めず、まず core に消費処理のトランザクション契約を追加し、Report がそれを利用するだけで対応できるかを確認しました。

トランザクションの実行は、複数のコンシューマーが再利用できる基盤機能です。共通入口へ集約すれば、個々のリスナーがアノテーションやプロキシ呼び出しに暗黙に依存する部分を減らせます。同時に、今回の修正で触る業務範囲も抑えられます。

採用した実装では、共通リスナーにトランザクションを明示的に有効化するスイッチを追加し、TransactionTemplate で業務の消費処理を包みました。既定は従来どおり非トランザクションで、必要なリスナーだけが有効にします。例外は RocketMQ に伝播してリトライ処理へ渡します。トランザクションを要求しているのにマネージャーがなければ、黙って非トランザクション実行へ切り替えず、その場でエラーにします。

Report は承認業務の構造を保ったまま、この能力へ切り替えました。まず消費失敗時のローカル DB ロールバックに、共通でテスト可能な実行境界を与える、という明確な修正目標です。

一か所の修正から類似実装の確認へ

最初の変更後、ほかのリスナーにもトランザクションが必要か、AI に調査を依頼しました。認可、フレームワーク、基盤、レポートなどのモジュールへ確認範囲を広げました。

すべてを一律に有効化したわけではありません。ローカル DB の状態を更新する処理は共通機能へ移し、キャッシュや設定の更新だけなら DB トランザクションは不要としました。メール、SMS、ファイルアップロードといった外部操作も、ローカルトランザクションを有効にするだけでは取り消せません。

対話中の実行記録には、コミット、例外時のロールバック、必要なトランザクションマネージャーがない場合の即時失敗を確認するコンポーネントテストの成功が記されています。Report と、その後変更した複数の業務モジュールについても、コンパイル確認が行われました。

確認できた範囲で結論を述べる

この記録が示すのは、共通コンポーネントのトランザクションテストと業務モジュールのコンパイル確認です。実際の業務効果を判断するには、消費例外後の DB 状態、再配信、通知の動作を実際のフローで確認する必要があります。

ローカルトランザクションだけでは、重複消費、リトライ上限到達、外部への副作用、DB コミットとメッセージ送信の間にある障害の余地は解消しません。承認失敗の状態を戻すか残すか、通知をいつ送るかは、業務の意味に沿って引き続き設計すべき点です。

AI はモジュールをまたぐコードの読解、候補案の整理、変更の実行を支援しました。私は修正目標、共通機能の所属、変更範囲、受け入れ条件を継続して判断しました。一度に生成できるコード量以上に、こうした協働こそ伝えたい AI 活用能力です。

4. このサイトも継続的な協働の例

この個人サイトは具体例の一つです。記事、開発事例、経歴、多言語対応、ダークモードは、会話と修正を重ねながら形になりました。

最初は方向だけの要望も多くありました。静かな日本の編集的なデザインに近づけたい、事例は業務を伝える内容にしたい、記事を読み終えた後の推薦と戻る操作を分かりやすくしたい、といったものです。

実際のページを見て、何を先に置くか、どの余白が必要か、不要な区切り線はどれか、同種のボタンが本当に揃っているかを詰めていきました。

記事末尾の調整はその典型です。「関連事例」と「次に読む」を左右に並べ、次に同じデザインのバナーへ揃えました。その後、区分名をバナー内へ移し、タイトルを小さくして一行で省略表示し、共有と一覧へ戻るボタンの位置を修正しました。

左右に並べることで構造は決まります。視覚的な優先順位、文字の密度、操作同士の関係は、描画されたページでさらに判断する必要があります。AI はコードの修正を手伝えますが、何が成立していないかを伝え、次の結果で解決したかを確認する役割は残ります。

方向を示した後に結果を観察し、違和感を実行可能な修正要求へ変える。この経験で、協働に必要なことが具体的になりました。

5. 口述原稿では Gemini の表現を好む

開発のほかに、Agent を操作して創業者の発信を支援することも試しています。動画などで話す原稿づくりは、その仕事の一つです。

実際の人が自然に話せる文章が必要です。主張が明確か、声に出せる文か、本人らしい語り口か、聞き手がついていけるかによって、使える原稿かどうかが変わります。

このような仕事では、Gemini の文章は人らしく、AI らしさが薄いと感じています。その表現を、さらに修正する出発点として選ぶことが多いです。

ただし、滑らかに読めるだけで納品できるわけではありません。創業者が主張に同意するか、資料が裏づけているか、推測を事実にしていないかを人が確かめます。本人の経験、企業の成果、具体的な数値は、話を完成させるためにモデルが補ってよい内容ではありません。

複数のツールを使う理由もここにあります。開発と口述原稿では成果の評価基準が異なります。すべてに同じ表現を求めるより、仕事に合った協働の仕方を選びたいと考えています。

6. 私が伝えたい AI 活用能力

継続して使う中で、三つの力を重視するようになりました。曖昧な考えを明確にすること、既存の制約内でツールと作業を進めること、結果が要求を満たすか判断することです。

開発では業務境界、設計、検証に、文章では受け手、事実、表現に判断が関わります。モデルは多くの工程に参加できますが、どの結果を採用するかは人が決めます。

個人の仕事で AI を活用することと、継続して運用する AI 製品を作ることには、それぞれ異なる要件もあります。LAIFE AI の開発事例では、健康情報、AI アシスタント、サービス運営をどうつなげたかを紹介しています。「AI 時代のソフトウェアエンジニアリング：仕様・制約・検証」では、AI の実装を確認する方法を掘り下げています。

新しいツールも引き続き試したいと思っています。AI によって、アイデアを目に見え、議論できる段階まで進めやすくなりました。そこから実際に使える成果へ磨く仕事が、さらに続きます。