AIにBetできていますか？
皆さんはAIを使ってコーディングや、その他の業務を効率化していますか？
調べると出てくるようなものもありますが、
実際にこうやってるよ、というものを簡単に紹介しようかなと思います。
*多分そんなに特殊な使い方はしていないと思いますが、主にAIとの共存系の使い方の話です。
読むのが面倒くさい方向けに
Google NotebookLMの音声でもどうぞ（言葉などがおかしいものがいくつかあります）
現在はどう使っているか
2025/07 現在は、開発にはClaude Code Maxをメインに使っています。
Gemini CLIはサブ的な位置づけではありつつも、Claudeとコラボレーションするようにして相互補完的に使っています。
HタスクのあとにGemini CLIを使ってコードレビューをしてもらうようにしたり、
複数のAIでコラボレーションさせることで、なるべく多角的な視点で評価するような仕組みにしたいと考えて
コーディング周りは大体そんな感じでやっています。
Hooksが発表されて楽になった・・・
下記のものもAI同士でコラボレーションできますので是非どうぞ（実際にこれも利用しています。）
Gemini CLIに投げるときも書きみたいにするとそのまま投げてくれたりしますので、
複数利用されている方はどうぞ
$ gemini --prompt "Code review request: <paths or codes>"
開発用途以外では用途によって使い分けているのもありますが、
日常業務的な、
たとえばスプレッドシートのデータを集計したり簡単な分析を行うような場合は、
Claude DesktopにMCPサーバ（ローカル・リモート含め）を設定して利用しています。
大きなデータを対象とする場合は、duckdbを利用して関節参照的な形でデータを利用できるようにして
Claude DesktopからduckdbのMCPサーバを経由して分析を走らせたりしています。
設定も簡単！
コンテキストなどが必要な場合は、
自作のMCPサーバでコンテキストを提供できるようにしていますので、
Claude DesktopやClaude Code、Gemini CLIなどからコンテキストを参照しながら分析を行うようにしています。
これだけでも相当楽になったなぁというのが実感できており、
現在はアプリケーション自体に組み込めるようにAIエージェントを少しずつ作ったり、
CQRS+ESを組み合わせて簡易RAG・コンテキストを提供できるような仕組みを作ったり実験しているところです。
こんなようなやつ
flowchart LR
subgraph Write-Side
A[API / Command] --> B[Actor]
B --> C[(Event Store)]
end
subgraph Projection
C --> D[Projection Worker]
D --> E[(Read Model DB)]
D --> F[Embedding Service]
F --> G[(Vector Store<br>DuckDB VSS or Vector DB)]
end
subgraph AI Context Hub
E & G --> H[MCP Resource / Tool]
H --> I[LLM / AI Service]
I -->|AI-Event| C
end
この一部は 設計ナイト2025【オフライン】でも紹介します
ドリフトやバイアスの問題もあるので、
簡単にできるようになったぜ！とは言えない問題も出てきますが、
1年前と比べると多くの可能性が広がっているなぁと感じています。
小さい処理の修正やプロトタイプ的なコードはDevinやCodexで十分なことも多く、
移動中に指示を出しておいてあとでインタラクティブに開発を進める、
みたいなこともよくやっています。
データベースリファクタリングやパフォーマンス改善系は、
各種データベースに対応したMCPサーバを介して色々やっています。
ライブラリの使い方をAIが見に行ったりもしてくれるので、DeepWiki MCP Serverはぜひ設定しよう！
ドキュメントはAIとともに作る
コンテキストなどを提供しなければなかなかうまく表現されないことも多いですよね？
そのために構造化されたドキュメントなどが必要になるわけですが、
レガシープロジェクトではなかなかドキュメントが整備されていないことも多いです。
が、さすがAI。
小さい範囲でシーケンス図を作成したり、
オブジェクトモデルなどのドキュメントを作成するのは得意です。
また、データベースなどもMCPサーバを利用するとスキーマ情報なども参照できるので、
インピーダンスミスマッチや、パフォーマンスの問題もかなり早く把握することができるようになりました。
これらを小さい範囲から始めていくことで、
自然とドキュメントが整備されていくような形にしています。
すべて揃っているわけではありませんが・・・。
用語集と合わせて、機能やプロジェクトの背景と合わせてドメインモデル図を作成したり、
シーケンス図を作成するのは割と日常的に利用しています（mermaidでいつも記述しています）。
勉強会やカンファレンスのスライドを作成するときと同じようなもんです。
こういったドキュメントをAIと一緒に作成していくことでプロジェクトのコンテキストをしっかりと把握できるようになり、
AIに指示を出すときも、より正確な指示ができるようになります。
┌─────────────────────────────────────────────────────────────┐ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Action │ │ Domain │ │ Persistence │ │ │ │ (Handler) │--->│ (Logic) │--->│ (Data) │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ ↑ ↑ ↑ │ │ │ │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Payload │ │ Value │ │ DB │ │ │ │ (Request) │ │ (Objects) │ │ (Access) │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘
数分で終わるものもあれば、レガシーなプロジェクトではなかなか時間がかかる場合もありますが、
それでも人が調べて書くよりも圧倒的に早く、
利用しないだけで損をしているなぁと思います。
用語集は絶対につくろう
多分みなさんもプロジェクト内の言葉や、開発者独自の言葉などがあると思います。
普段はとくに意識することなくコミュニケーションで利用していると思いますが、
エージェントなどに指示を出すときは、これらの用語をしっかりと定義しておくことが重要です。
AIは人間と同じように、なんとなく暗黙知を共有しているわけではありません。
人間は人それぞれが言葉から連想できる何かしらのイメージを共有して物事を把握していますが、
AIはなんとなくこれっぽいコンテキストや前後の関係をうまく参照しにいって理解する、ということはできません。
プロジェクトで利用することばは、明確な文章化とともにコンテキストとして利用できるように徹底しましょう！
また、機能ごとに細分化して用語集を作成するのもポイントです。
これはあとの開発で例でも説明しますが、
プロジェクトの言葉だけでも、かなり抽象的なものになることが多いです。
機能ごとに同じ言葉だけど微妙に違うもの、ありますよね？
これらも機能ごとにしっかりと明記しておくのがオススメです。
# XX機能 用語集 ## 商品 ここでいう商品は、販売可能な状態となった商品を指す。 販売可能とは、在庫があり、販売価格が設定されている状態を指す。 ## 住所 ここでいう住所は、顧客の配送先住所を指す。 配送先住所は、郵便番号、都道府県、市区町村、番地、建物名などを含む。 住所は、配送先として登録されているものを指し、 顧客が注文時に指定した配送先住所に基づいて商品が配送される。
みたいな感じです。
雑に指示しない
機械学習なども自分で取り組んでいるのもあり、すべてうまくやってくれるわけではないのはわかっていますが、
やはり人間なので勝手に期待値が上がってしまうこともあります。
ドラえもんではない！というのはわかっていつつも、やはり
なになにを実装してくれ！
という指示を投げてしまうことがたくさんありました
その結果、思ったものと違うものが出てきたり期待値に届かなくてイライラしてしまうことも・・。
（ありますよね？）
その結果うまくできるまで何度もやり直したり、
テストコードの実装を指示するとムダなキャストばかりでどんどん複雑になったり、
そもそもテストコードがモックに対してテストしていたり、
オアーーーーーーーーということが多々ありますよね？
1日で1万くらい飛んだことも
設計方針やアーキテクチャの指示を出しても、うまくいかない・・
CursorやClineなどのツールに対応したコンテキストもかなり多く作ったりしました。
お金が直結しているために一度でうまくいくように試行錯誤をしたり、
Claude Code Maxからの流れであまり気にしなくても良くなったというのはあります。
が、「人間がレビューをしなければならない」というのは今のところおおきくかわっていないので、
単純に動くだけで良いというわけではなく、
実際の運用保守の観点で指示の質が落ちてもよいというわけではありません。
小さく動くコード
さまざまなコンテキストとともに、各レイヤーや処理ごとに実際に動くお手本になるコードを自分で用意し、
設計指針やアーキテクチャなどのコンテキストを参照できるようにしており、
全然違うものが出てくる！ということはすくなくなりました。
また一度にでかいコンテキストや文章を突っ込みすぎてしまうと、
達成すべき目標が他のものに影響されてしまって意図しない結果になることが多いので、
与える情報も巨大にならないようにし、
各処理ごとのコンテキストに切り出して利用するようにしています。
とはいえ、設計の知識がないと的確に指示できないと思いますので、
チームやプロジェクトの設計方針やアーキテクチャをしっかりとみんなで共有・理解しておくことが重要です。
自分自身では各レイヤーごとや機能ごとにどのような処理を行うのか、
などの指針と文章化をしており、MCPサーバのPromptやResourceとして参照できるようにしてあったり、
GitHubのリポジトリにテンプレート的に利用できるように残しておいたりしています。
個人的なポイント
クリーンアーキテクチャやDDDなどの言葉で指示を出さないのをオススメします。
クリーンアーキテクチャは定量的な絶対な設計パターンを指すものでもありませんし、
DDDもコード以外のドメイン知識やビジネスロジックをしっかりと理解・ドキュメント化をしていないとうまくいかないことが多いです。
いわゆるサービス乱用、Table Data Gatewayなどのアンチパターンに陥ることも多いので（リポジトリを何個も使ったり）、
きれいに見えてもオブジェクトグラフのためのコードや、
複雑なコードにしかなりません。
前述の用語集などと合わせて機能ごとの集約とはなにか、とか
実装パターンの例と併せて明確に指示を出すのがオススメです。
こういったものがなかったり、開発者自身がしっかりと言葉と内容を理解していないとほしいアウトプットは得られません。
まだない場合は、まずはAIと壁打ちしながら作っていくと良いです。
用語集からぜひ作っていきましょう。
イベントストーミングやドメインモデリングなどの手法を使って、
ドメイン知識をしっかりと可視化を忘れずに。
コードを書く前にこのあたりもAIと一緒に作っていくとイメージもしやすいと思います。
作ったドキュメントをGoogle NotebookLMを利用して第三者的にレビューしてもらったり、
音声で聞いて違和感がないかどうかなどセルフチェックがかなり高品質できるようになっているので、
ぜひ活用してみてください。（自分自身もよくやっています）
LLMの学習ソースのはなしではありますが、
ソースが多ければ多いほど正しいものような扱いで出力されることが多くあります。
RepositoryやServiceという曖昧な言葉で指示するとほぼアンチパターンのようなコードがでてきます
またそれらを連想させるようなコードを散りばめておくと、
コード例から連想されるようにどうしても雑なRepositoryやServiceが出てきます。
あえてプロジェクト内で用語を使わないようにするのもひとつかなと思います。
（実際に自分で開発しているものはそういった用語はすべて排除しています。）
型変換をうまくやろう
レイヤーまたぎの処理や、
他の関数やメソッドを呼び出すときに、
意図しない実装コードや意図しない複雑な型変換が行われることがよくあります。
ひとつの型で複数の意味をもたせるようにしてしまうと、
AIから出力されるコードも同様にかなり巨大で、
複雑なコードや複雑な処理に直結します。
リクエストレスポンス用の型と、アプリケーション内で注力したい処理の型、
データベース用の型などをしっかりと分離しておき、
型変換なども明確に用意されているコード生成などの仕組みを合わせて利用するとかなりスムーズです。
言語ごとにポイントはありますが、
自分の場合データ関係の処理はsqlcを利用し、
インターナルなサーバ間のやり取りや実装コード上もレイヤー間のやりとりはProtocol Buffersを利用しています。
sqlc等の場合は、
クエリ自体はMCPサーバを介して実際のスキーマ情報とテーブルの中身からクエリを作成し、
あとはコード生成を行うだけとなりますので、
おかしな処理が出力されるということはそもそもほとんどありません。
レスポンスフォーマットには同様にProtocol Buffersや、
OpenAPIを利用していることが多いです（TypeSpec移行を徐々にしますが）。
このような仕組みを利用することで、
コード上で勝手な実装を行うこともなくなり、
各レイヤーに関する技術的なドキュメントとしても活用できます。
実装戦略は大事
CursorやClineなどのツールを利用している方は利用していると思いますが、
すぐに実装に入るのではなくて、
ここまで記載したような内容を踏まえて、実装戦略を作ってもらいましょう。
実装戦略は次のようなものを主に含めます。
- どのような機能を実装するのか
- どのようなアーキテクチャで実装するのか
- どのような設計で実装するのか
- どのようなテストを行うのか
大きな内容の指示ではなく、たとえばデータベース操作を抽象化する部分だけだったり、
HTTPハンドラーのレスポンスを定義する部分だけなど、
小さく切り出して実装戦略を作成してもらうのがオススメです。
そんでもってこの実装戦略をドキュメントとして出力しておきます。
Claude Codeなどでresumeなどはありますが、前の指示内容を意図したまま実行してくれるわけではありません。
（いきなり実装の方針が変わったりなどが頻繁にある）
また残しておくと自分たちのためにもなりますし、
compaction実行後でも安全に参照できるデータとして残ります。
実装戦略の内容がイマイチであれば、自分で修正することもできますので、
チャットだけでやり取りするよりも確実なものになります。
データ分析や戦略づくり
データ分析や戦略づくりは、AIと一緒に行うことでかなり効率化できます。
エンジニアでもデータ分析やプロダクトの戦略づくりを行うことが多いと思います。
MCPサーバを介してデータベースの情報を参照しながら、
インターネット上の情報をAIで検索してもらい、そこから得られた情報をもとにどのような戦略をたてるのか、
可視化していくことができます。
前述のようにduckdbがかなり手軽で便利に利用できるので、
データ基盤などが整備されていない場合でも、
複数のデータソースを結合したり集計ができます。
またClaude DesktopでChart.jsを使って可視化をしてくれるので、
BIツールで整備する前に手元で簡単に試したり、
簡単なアルゴリズムを用いた分析を行うことができます。
季節性の分析や予測を行いたい場合は、ARIMA・Propheモデルなどを利用して時系列分析を行うこともできます。
重回帰分析やクラスター分析などはやりたいことに合わせてコード生成してもらい、
Pythonを実行するだけで割と簡単に分析などができます。
このあたりだけでもかなり効率化できると思います。
エンジニア以外の方にもぜひ利用方法を教えてあげてください。
まとめ
エンジニアリングに関する仕事の内容は去年後半から大きく変化したなぁと感じています。
自分たちのプロダクトに合わせたコンテキストや開発方針は教科書のようなものがあるわけではありませんので、
AIといっしょに用意して整えていくだけで、ものすごく効率化できます。
MCPサーバも組み合わせるだけで、よりうまく利用できるようになりますので
みなさんもぜひ色々やってみてください。
MCPサーバを利用するときは、きちんとスキャンしたりするのを忘れないようにしましょう。
悪意のあるコードが混入している場合もありますので、
何も調べずに利用するのは危険なので、しっかりと調べてから利用しましょう！
最後に弊社では、AI駆動開発に関するツール導入や開発を積極的に行っていますので、
興味のある方はぜひご連絡ください！
Pittaでカジュアル面談も受付中！
