この記事は Akerun Advent Calendar 2025 - Qiita の16日目の記事です。
こんにちは。Esperna - Qiita です。 今年は仕事でもプライベートでも、AIに触れる時間が増えました。 一番変わったのは、開発の量やスピードではなく、AIとの向き合い方でした。 この記事では、私のAIとの向き合い方がこの1年でどう変わったかを、具体的な運用ルールと一緒に振り返ります。 （前提として、判断や責任をAIに委ねるのではなく、あくまで人間が握るつもりで運用しています。）
2025/5月：時間を短縮する「便利なツール」としてのAI
Cursorを導入した当初は、運用保守のプロジェクトでAIに単体テストを書かせていました。 モック作成、パラメタライズドテスト、細かいリファクタリング、コメントの英文化など面倒だけど必要な作業が短くなるのは素直にうれしかったです。 ただ、この時点ではまだ「便利なツール」でした。 便利さの次に来たのは、疑いの増加でした。 テストがFailしたときに、
- 実装が間違っているのか
- テストが間違っているのか
- それとも両方とも間違っているのか
を疑うのと同じように、AIの出力に対しても同様の問いが増えました。 面白いのは、これは単に不安が増えたのではなく、考える幅が一段広がった感覚があったことです。自問自答はもともとしていましたが、AIが入ると、その自問が対話になり、思考が外に出やすくなりました。ここから、作業の手触りが変わり始めました。
2025/7月：AIを鵜呑みにしないための「運用」（ラベルとRules）
この頃、Linux / Node.js / Go といった技術スタック中心の開発から、Zephyr / C / 電子回路など、より低レイヤーのファームウェア開発にシフトしました。 それに伴い、習得すべき知識・スキルが増え、必要なインプット量も以前より格段に増えました。 最初はドキュメントを1つずつ読み込んでいましたが、そもそも一日に読める量には限界があります。 そこで、量の多いドキュメントは一旦NotebookLMに読み込ませて要約し、読むようにしました。 ここで私が意識したのは、要約を答えとして扱わないことです。少しでもわからない点や違和感があれば、納得いくまで質問します。結果として、少なくとも自分のケースでは理解に入るまでの時間が短くなり、考える幅も一段広がったように感じました。 一方で、AIを使う量が増えるほど「運用」が重要になります。 AIとのやり取りはMCPを使ってWikiやチケットにまとめるようにし、その際にAI出力であることを明示的にラベルするようにしました。さらに、AIの回答には確信度（Red/Yellow/Green）を出力してもらうようにしています。 これらは、AIがハルシネーションを起こし得る以上、読む側が鵜呑みにしないためです。 私の場合、次のようなサインが出たらそこで止めて、定義や根拠（一次情報）に戻るようにしています。
- 根拠（一次情報の該当箇所）が示せない
- 用語の定義が曖昧
- 前後で主張が変わる
確信度はAIの自己申告であり、正しさの保証ではありません。むしろ「自信満々でも間違える」前提で、私が疑うきっかけとして扱っています。 このあたりの性質については、Berryman / ZieglerのLLMのプロンプトエンジニアリングの説明が参考になりました。 運用を固定するために、CursorのRulesにも記載を追加しました。 Rulesは他にもありますが、ここでは趣旨に関係するものだけ以下に抜粋します。
- 指定がない限り出力はmarkdownで書くこと
- 単に用語の意味を知りたいなどの単純な質問の場合、確信度(Red:50%以下、Yellow:50%より大きく90%未満、Green:90％以上)とともに答えること。確信度はアイコンでRed,Yellow,Greenで示すこと
- 案を考えてください／提案してくださいと言われた時は、見落とし確認→不明点の質問→複数案→メリットデメリット整理→最適案と根拠、の順で出す
2025/11月：AIは「観測できる範囲」しか答えられない
11月にHWの動作確認をするためにドライバを実装していて、数週間ハマった出来事がありました。 原因は、デバイスが状態を持っていて、こちらの予期しない状態（ハング状態）に入っていたという問題でした。 このとき痛感したのは、私の使い方ではAIが答えられるのはソースコード、仕様、デバッグログなど、こちらが与えたコンテキストの範囲に限られる、ということです。 観測がない領域（ハードウェアの状態）は分からないか推測になりやすいです。 だからこそ、鵜呑みにしない運用と、観測を増やす判断が重要になりました。 具体的には、ログや波形を増やすだけでなく、自分の外にある経験（先輩の知見）に当たりにいくことも含めて、手掛かりを増やすようにしました。この件は、先輩に相談したことで突破口が見えました。
2025/12月その1：段階的なプロンプトで回す、自分用Review study
自分が知らないドメインのレビューをすることが、圧倒的に増えてきました。 最初はレビュー内容に対して、AIに分からない点を1つ1つ確認しながら進めていましたが、概念が多いと事前調査に時間がかかります。 困っていたところ、優秀な後輩に「ChatGPTのStudyモード相当のものをスラッシュコマンドで作ればいい」とアドバイスをもらいました。 そこで自分用にReview studyコマンドを作り、レビューを学習と観点拡張の場に変えました。 狙いは、いきなりレビューに入るのではなく、用語→観点→レビューと段階を分けることです。結果として、レビュー前に自分の知らない概念を整理し、理解度チェックを挟み、観点を洗い出した上で、必要だと判断したものだけコメントを残せるようになりました。 （段階化した方が結果が安定しやすい、という考え方はBerryman / ZieglerのLLMのプロンプトエンジニアリングでも参考になる点が多かったです。） ここまで来ると、AIは単なるツールというより、分からない知識をフォローしながら一緒にレビューしてくれる同僚に近い存在になりました。 さらに面白いのは、レビュー対象のMRも同僚がAIを使って生成・監修しており、私もAIを使って理解しながらコメントする点です。コミュニケーションが直接のやり取りというより、AIを介して間接的に成立する感覚が出てきました。
▶︎ Review study コマンドの中身（和訳）
description: 「プログラミングコードレビューのための対話型学習モード。用語理解、レビューポイント、メンター風のコードレビューをカバー。ユーザープロンプトは日本語のままです。」 # レビュー学習モード ユーザー入力（例：MRタイトルやコード差分）は`$ARGUMENTS`として渡されます。 ## 1️⃣ 対話型学習フェーズ 1. Claudeがユーザーに質問： > 「わからない用語や概念はありますか？」 2. ユーザーが理解できない用語や概念を提示 3. Claudeが技術的背景と目的を詳細かつ親しみやすい指導者調で説明 4. ユーザーが納得するまで必要に応じて繰り返し 5. Claudeが理解度確認の短文クイズを提示 - 選択式または穴埋め形式 - ユーザーの回答に基づく解説を提供 ## 2️⃣ 確認ポイントフェーズ 1. 用語と概念が理解されたら 2. 約5つの主要な確認ポイントを提示 - 各ポイントの根拠とシンプルな設計判断の指針を含める 3. コードレビューへ進む - `$ARGUMENTS`からのコードまたは差分を確認 - 問題点を指摘し改善案を提案 - 重要度とリスクについてコメント - 友好的なメンター的な口調を保つ ## 3️⃣ 対話型フォローアップ - レビューポイントとコードフィードバック提示後、ユーザーに尋ねる： > 「もっと深掘りしたい項目はある？それとも次に進む？」 - ユーザーの応答に基づき、追加説明や例を継続する
2025/12月その2：テストファーストをAIと回す
組み込みソフトウェア開発では、実機環境でテストファーストを回すハードルが下がったと感じています。 まずデータシートをClaude CodeまたはNotebookLMに読み込ませて機能を整理してもらい、同時に自分でも斜め読みして不明点は納得いくまで質問します。その後、主要なテストケースとテストコードを作ってもらい、ビルドしたバイナリをJ-Linkでボードに書き込みます。ドライバ実装が無いのでテストはFailします。 その後ドライバを実装し、Failしたら誤っているのは「実装か／テストか／両方か」を疑います。 このとき参照するコンテキストは、仕様（データシート）やソースコードだけでなく、J-Linkの出力やオシロスコープの波形なども含まれます。これらのコンテキストが揃っている範囲では、AIと対話しながら仮説を更新でき、1人で考えるより思考の幅が広がったように感じます。 同じ密度で同僚に付き合ってもらうのは現実的には難しいので、AI相手だと遠慮なく深掘りできるのは助かっています。
まとめ：AIは「便利ツール」から、チームのコミュニケーションを変え得る「通訳者（L8以上の層）」へ
AIは単に作業時間を短くし、大量の情報処理を行う便利ツールではなく、対話を通して思考の幅を広げ、ある意味で人間の認知能力を拡張するようなものだと捉えています。一方で最近は、仕事というコンテキストにおいて、与えられたコンテキストの範囲内で、AIは「同僚」としてだけでなく、理解と説明の往復に伴う摩擦を減らすことで、チームのコミュニケーションの形を変え得る「通訳者」として働きつつある、と感じています。OSI参照モデルで言えば、これはアプリケーション層（L7）の上に、人間同士の会話や議論、意思決定をスムーズにする新たな通信層（L8以上の層）が生まれつつあるということかもしれません。
参考文献
www.oreilly.co.jp qiita.com en.wikipedia.org
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp Akerunにご興味のある方はこちらから
