この記事はOPENLOGI Advent Calendar 2025の3日目の記事です。
2日目は、@imahellob99 さんの Slack App × GAS × GeminiでAIキャラクターボットを作ってみた でした。思わず作ってみたくなるボットに関する小粋な記事です。まだの方は是非読んでみてください。
ごあいさつ
さて改めまして、8月にオープンロジに入社しました @busyoumono99 です。
オープンロジの2025年3日目のアドベントカレンダーを担当させて頂きます。
以前の投稿から大分経過しました。元気かわからんけど生きてたね。という事で今回は私が現在行っているAIを利用した開発の現状について共有したいと思います。
はじめに
弊社では、最近のAI(大規模言語モデル)を活用した開発が進んでいます。
利用しているAIは4つ。Gemini、Copilot、Claude、Codexです。
利用したいAIを選択して申請しています。私は4つとも利用させて頂いています(ありがてぇ)。
また社内の活動としましてはAIに関するチームが幾つか立ち上がり、10名程度のメンバーが参加しています。
それぞれの活動でAIを研究したり、AIの利用を推進したり、情報共有を行っています。
私も例に漏れずAIを利用して開発しているのですが、なかなか使いこなしている感がありません。
普通のITの学習曲線であれば、「完全に理解した→なにもわからない→チョットデキル」の例の曲線を描くのですが、「完全に理解した」も行った感じも無いです。
https://x.com/ito_yusaku/status/1042604780718157824
恐らくですが、AI関連の展開が早すぎて、理解が追いつかないのではないかと思っています。
そんな訳でマサカリ投げ合う妖精さんが現れるQiitaに私の現状の利用方法を共有して、無事瀕死になるのを目指して恥を忍んで投稿します。
道具
以下AIを利用するにあたって作業効率が上がった道具・ソフトを紹介します。
モニタ
モニタの追加。AI用にモニタを1台追加しました。これだけでも作業効率が上がります。
音声入力
プロンプトを入力するのに少し利用しています。MacOSの純正の音声入力を利用しています。
課金するような上等なアプリは利用していません。(真面目に探していません。)
音声入力を利用することで、プロンプトの入力が非常に楽になります。
Raycast
RaycastはMacOS用のランチャーアプリです。特にsnippets機能が便利で、よく使うプロンプトを登録しておくことで、素早く呼び出せます。
またsnippetsは https://manual.raycast.com/dynamic-placeholders にあるように動的プレースホルダーを利用できるので、プロンプトの一部を変数化できます。これはAIに限らず通常の業務でも便利に使えます。
私がRaycastのsnipettsを利用する理由は、各AIツール毎にプロンプトを登録する機能(例:Claude codeのcustamu command)があります。しかし利用するAIツールによってつど作成(設定する)のが面倒なので、snippetsで一元管理しています。
Warp
Macのターミナルソフトです。WarpにはAI機能が組み込まれておりますが、これは利用していません。
元々はターミナルソフトのiTerm2を利用していたのですが、Warpに乗り換えました。
Warpの気に入った点は以下です。
- 履歴がブロックという概念で管理されており、コマンドとその出力がセットで見やすい
- 入力のポイント(キャレット)がクリックやAlt+矢印キーで簡単に移動できる
前提
業務知識の複雑さ
弊社は物流業界向けのSaaSを提供しており、業務知識が非常に複雑です。
まず、関係者が多い。荷主、倉庫業者、配送業者、消費者など多くのステークホルダーが存在します。
次に、物流特有の制限・ルールが多い。例えば、温度管理が必要な商品、危険物の取り扱い、配送時間帯の指定などがあります。
といった具合で全体を完璧に把握している人は多分いないんじゃないかと思います。
社内Wikiの整備状況
AIを利用する以前から社内WikiをGrowiで運用しており、長年の情報の蓄積があります。
チームによって情報の整理具合には差がありますが、基本的にはWikiを参照すれば大抵の情報は得られます。
会社でのAIの利用方針
AIは会社でチームプランを契約して学習されないような設定にしています。
また社内の情報セキュリティポリシーに従い、機密情報・個人情報は入力しないようにしています。
AIの共通の設定
MCP
MCPは4つのAIに共通して利用しています。「トークンを無駄に消費するんじゃー」というツッコミもあるかと思いますが、現状脳死で設定しております。
この辺は今後の課題だとは思っています。
音で通知
他の作業していても気づくように各AIツールの設定で音声通知するように設定しています。
もう標準機能でいいんじゃなかろうかと思う今日このごろです。
AIの使い分け
以下私が利用しているAIの使い分けです。
Gemini cli
Geminiは主に調査で利用しています。MCPで社内Wikiの参照、コードの解析、Slackの過去ログの参照などを行っています。
後述するドキュメントの生成やコード生成には全く利用しておらず相談役の立場で利用しています。
Claude code
メインで利用しているAIです。ドキュメントの生成、コード生成、コードの解析など幅広く利用しています。
カスタムコマンドはRaycastのsnippetsを利用している関係で利用していません。
逆にサブエージェントはスレッドが分かれている・トークンの消費が少なくなるなどの利点があるため積極的に利用しています。
Claude codeはツールセットが優秀でとにかく使いやすいという印象です。
Codex
コードレビューでは必ず利用します。Codexのモデルによる /review コマンドは非常に優秀で、バグの指摘や改善点の提案を的確に行ってくれます。
指摘内容が一見間違っているように見えても、よくよく調査すると正しいことが多いです。
また、Claude codeでドキュメント生成・コードの実装が行き詰まったらCodexで解決しています。
Copilot
AI エージェントで実装せずに、自力で実装する場合に利用しています。VSCodeの標準機能で利用できるため、非常に手軽です。
また、コードの補完精度が非常に高く、実装中に自然と次々にコードが補完されていくため、実装速度が向上します。
AI利用で意識していること
プロンプトエンジニアリング
AIは私の状況や目的や意図が全くわからないです。当たり前ですが目も耳もないという事を意識しています。
そのためプロンプトエンジニアリングは非常に重要です。良いプロンプトを作成することで、私の状況や意図を伝えてAIに正確に把握してもらう必要があります。
私は以下の点を意識しています。
- 明確で具体的な指示を与える
- 期待する出力形式を指定する
- 必要なコンテキスト情報(文脈)を提供する
- AIに期待する役割を明確に伝える(例: あなたは優秀なソフトウェアエンジニアです)
出力の検証
AIエージェントを利用して業務を実施した場合、そのままだとAIが何を実施したのかは基本的にはわかりません。
その「何も分からん」を回避する為に、実施した内容を観測する仕組みが必要です。
そのためAIの出力は必ず検証するようにしています。
生成されたドキュメントをレビューして、内容が正確であるかどうかを確認します。
コード生成の場合はTDDで開発を進めて、生成されたコードが正しく動作するかどうかを確認します。
プロンプトを書きすぎない
プロンプトが長すぎると、AIが重要な情報を見逃す可能性があります。必要最低限の情報を提供し、過剰な情報・重複する情報は避けるようにしています。
プロンプトの引き算を強く意識しています。
AIが指示内容を忘れる件
AIは長い会話や複雑な指示を忘れることがあります。これは現状のAIの特性で避ける事はできません。
特に複数のステップが必要なタスクでは、途中で指示内容を見失うことがあります。
この問題を軽減するために、以下の方法を試しています。
- 適切なタイミングでClaude codeの
/clearコマンドに相当するリセット操作を行う - なるべく小さいタスクに分割して処理する
- 小さいタスクにわけるので、つど成果物を出力・保存して、以後のステップで必要な分だけ参照するようにする
開発の手順
開発と言っても入社してから担当した業務はバグ修正や改善対応のみなので、機能開発などではまた話が変わるかもしれません。
Spec driven developmentを意識しています。正しく理解している気は全くしませんが、手探りでやっています。
以下は私が担当したバグ修正や改善対応での手順です。
共通項目
- 各作業のコード以外のドキュメントは変更や方針転換などが発生した場合は都度更新しています
- 手作業でやるには非常に面倒だったこの作業もAIに任せる事で楽になりました
- 各作業の実行した作業ログを
work_log.mdとして保存しています- プロンプトとその結果の要約を記録しています
- AI エージェントが裏で実行したコマンドの履歴・結果も保存するように指示しています
-
work_log.mdはAIに読み込ませることはありません。自分の反省やAIの使い方の改善を行う為に保存しています
1. 要件の把握と初期準備
まずはバグ修正や改善対応の要件を把握します。
Claude codeのサブエージェント explorer を使い、Redmineのチケットや社内Wikiや過去のSlackログを使って必要な情報を収集します。
この際間違った情報を出す可能性があるため、情報の出典も必ず出すように指示しています。
情報の収集はAIに指示を出す為でもありますが、入社間もない自分自身の理解を深める為でもあります。
必要なら私が関係者へのヒアリングなどを通じて追加情報を収集します。
一旦上記を踏まえてブランチ名をAIに提案してもらい、作成します。
プロジェクト直下にチケット用のフォルダ #<チケット番号> を作成、その中に .gitignore を追加します。中身は * として保存します。
その後、調査した結果を research_report.md として保存します。
この調査ではGeminiも併用で調査しています。必要な追加情報あればClaude codeへ指示を出して収集します。
今後の課題
各案件ごとのフォルダはGoogle Driveに作成するのが筋なのですが、検証している時間が無いため現状ではローカルに作成しています。
ローカルにしているのはAIへ読み込ませるのが楽だからです。
2. 対応の検討
調査した情報を基に、対応方法を検討します。
Claude codeのサブエージェント analyst を利用して、問題の原因分析と対応策の提案を行います。
幾つかある対応策の中から最適なものをメリット・デメリットを提示して貰って私の判断で選択します。
この検討内容は analysis.md として保存します。
3. 計画の立案
収集した情報と対応案を基に(research_report.md、analysis.mdを読み込ませて)、作業計画を立案します。
Claude codeのサブエージェント planner を利用して、タスクの分解とスケジュールの作成を行います。
この時タスクはあくまで大雑把に分解する(フェーズ)だけに留め、詳細なタスク分解は次のステップで行います。
この計画内容は plan.md として保存します。
4. タスクの分解
計画に基づき、具体的なタスクを分解します。ほぼどういった実装するかもこの段階で決定します。
Claude codeのサブエージェント task-breakdown-assistant を利用して、各タスクの詳細な分解を行います。
作業がコードの実装であれば、TDDの観点でタスクを分解するように指示しています。
このタスク分解内容は tasks_<フェーズNo>.md として保存します。
5. 実装
分解したタスクに基づき、実装を行います。
Claude codeのサブエージェント developer を利用して、コードの生成とテストを繰り返しながら実装を進めます。
この項目の成果物はテストコードとプロダクトコードです。
GitへのコミットのコミットメッセージもClaude codeに作成して貰います。
6. レビュー
実装が完了したら、コードレビューを行います。
Claude code自身のレビューと Codexの /review コマンドを利用して、コードの品質チェックと改善点の提案を受けます。
指摘された内容を基にコードを修正します。
指摘内容によっては方針転換などもあり得るので、内容に応じてドキュメントの更新・再計画なども行います。
今後の課題
このレビュー内容は特に保存していませんが、今後は保存した方が良いかもと思っています。
7. PR作成
実装とレビューが完了したら、Pull Requestを作成します。
PRの説明文もClaude codeのサブエージェント pr-writer に作成して貰います。
弊社ではPRテンプレートを利用しているので、そのテンプレートに沿った内容で作成するように指示しています。
今後の展望というか希望というか
GoogleのAntigravityを使った開発が気になる今日この頃です。多分今後はメインで利用していく事になるんじゃないかなと思っています。
また、現状では各AIのツール毎に設定を作成する必要があるのですが、今後は各AIベンダーが協力して統一的な設定管理ができると良いなと思っています。mcpの設定を各ツール毎にするのは面倒だよね。
おわりに
長文にお付き合い頂きありがとうございました。
ほぼ全体にダメ出し・マサカリがくる可能性はあるだろうなと思いつつ、現状の共有をさせて頂きました。
何か1つでも参考になる情報があれば幸いです。