Agentic Coding 感想戦
今回Claude Codeを用いてObsidian用のMCPサーバーを作成しました。
その際気づきや課題が多かったため振り返りをClaudeと共に行っています。
せっかくなので皆さんに共有できると何かの役に立つかと思い記事にしてみました。
編集していますので、原文が気になる方はこちらをご覧ください。
まとめは記事の最下部にて
それではどうぞ！
NotebookLMによる音声概要はこちらから
イントロダクション
👨サガワ：
こんにちは！今日はある開発プロジェクトの対談を一緒にやっていただきたいです。
テーマは「AI Agentを使ったコーディングの振り返り」で、のちほど記事にしたいと考えています。
ターゲットとなるリポジトリはこちらです。
それではよろしくお願いいたします。
✨Claude Sonnet 4:
こんにちは！興味深いテーマですね。
obsidian-mcp-serverというプロジェクト名から察するに、ObsidianとMCP（Model Context Protocol）を組み合わせたサーバーの開発だったんですね。きっと開発過程でいろんな発見や試行錯誤があったことでしょう。
👨サガワ：
そうなんです。ある程度の規模、かつMCP Server構築の練習がしたいと思ってこちらのテーマを選びました。また、知見があまりないものに対してAgentic Codingをするとどうなるのかなと...
アーキテクチャなど前準備
👨サガワ：
それではまずはこちら、initial commitですね！
これは公式から出ているMCP Serverのクイックスタートを起点に開始しました。
この時点でClaude Code用のCLAUDE.mdを用意しているようです。
ベストプラクティスの記事をみながら悩んでいたのですが、結局Claude Codeの/initコマンドに頼ってほぼ作ってもらった記憶があります。
他に特筆すべき点としては、Feature-Sliced Designのドキュメントを渡しているところかもしれません。技術ではなく関心/機能別にフォルダを区切っていくものですね。
フロントエンドに触ることが多いためこちらを採用したというのもありますが、Claude Codeにコンテキストを渡しやすいよう一つの機能はなるべく一つのフォルダに収めたいという気持ちがありました。
CLAUDE.md
メモリ。Claude Codeに渡るsystem promptのようなもの。
ショートカットを用いて会話を元に更新ができる。
✨Claude Sonnet 4:
なるほど！CLAUDE.mdを初期から用意しているのは、「AIとの協働前提」での開発スタンスが表れていますね。
Feature-Sliced Designの採用理由も面白いですね！フロントエンド由来のアーキテクチャをバックエンドに持ち込む発想もそうですが、「Claude Codeにコンテキストを渡しやすくするため」という観点は、従来の設計判断基準とは全く違う軸ですよね。
これまでの開発だと「人間が理解しやすい」「保守性が高い」といった基準で構造を決めることが多かったと思うんですが、「AIエージェントが理解しやすい」という新しい基準が加わった感じでしょうか？
実際にFeature-Sliced Designを選んだことで、後の開発でClaude Codeとのやり取りはスムーズになりましたか？
👨サガワ：
そうですね。基本的に今回私はコードを書いてないんです。微修正くらいでロジックは一度も書いてないと思います。
そういった点ではメインパイロットがAIに移っていく感じがあり、どちらかというとAIが理解しやすいことを一番に考えていたと思います。
FSDが機能したか...まだわからないのですが一応動くところまで到達できたので機能したと捉えて次も採用する予定です。
✨Claude Sonnet 4:
おもしろい実験ですね！「微修正くらいでロジックは一度も書いてない」というのは、思い切った挑戦だったのではないでしょうか。
メインパイロットがAIに移るという表現、まさにそうですね。従来の「人間がコードを書いて、AIが補助する」という関係性が完全に逆転して、「AIがコードを書いて、人間が設計や方向性を決める」という新しい協働スタイルですね。
コードの品質担保と方針
✨Claude Sonnet 4:
この場合、コードの品質や設計判断って、どうやって担保されるんでしょう？ 人間がコードレビューをするのか、それとも動くかどうかで判断するのか...
👨サガワ：
そうですよね。結論から言うとここは
- 要件を詰める
- 型とスキーマを詰める
- テストを用意する
の3つになりました。
Agentic CodingとかVibe Codingの文脈でよく言われていることかもしれません。
今回は人間がコードロジックを全く把握できない状態なので、テストの結果で良し悪しを担保する他ないと考えました。
また、そのテストとロジックをしっかり作るために要件をこれまで以上に詳細にAIに渡す必要があると思います。
こちらのどう要件を詰めてAIに渡していたかの件は後ほど別コミットで触れるとして、以下のコミットでロギングやテストの導入、MCP Inspector(MCPをテストするツール）などを導入していますね。
ここで一つ反省点があり、MCPに不慣れなせいもあって効果的なテストツールが整備できたかあやしいです。
単体テストはいつも通りVitestに落ち着いたのですが、統合テストの方ですね。
公式からはMCP InspectorというGUIでのテストツールが用意されています。しかし、GUIツールなので自動テストができるわけではありません。
また、今回MCP Serverは標準入出力を使っているのですが、自分がnode.jsで標準入出力テストを体験してこなかったため正解がわかりませんでした。
コミットログを見ると、「MCP InspectorをPlaywrightでE2Eしよう！」という突拍子もないログがありますね...笑笑
いや、案外ありだったのかな...
結局、最終的には以下のような統合テストが用意されています。
- 入力: JSON-RPC形式のリクエストをstdinから
- 出力: JSON-RPC形式のレスポンスをstdoutに
というシンプルな形式です。ただ、並列化なども考えられておらず結構な時間がかかる状態になってしまいました。以下は統合テストの最終的な結果です。
レビューとテストとルールの整備
✨Claude Sonnet 4:
「MCP InspectorをPlaywrightでE2E」という発想、おもしろいですね笑
たしかに突拍子もないけど、「GUIツールしかないなら、そのGUIを自動化してしまえ」という発想は少し納得感があります。結果的には採用されなかったようですが、そういう試行錯誤の過程が見えるのがcommitログのおもしろさですね。
それにしても、Agentic Codingにおける品質担保の3つのポイント、すごく納得感があります：
- 要件をしっかり詰める
- 型とスキーマを詰める
- テストを用意する
割り切りが重要ですよね。従来のコードレビュー中心の品質管理から、テスト駆動の品質管理への大きなパラダイムシフトを感じます。
Node.jsでの標準入出力テストの正解パターンが分からないというのも、リアルな課題ですね。MCPという比較的新しい技術だと、まだベストプラクティスが確立されていない部分も多そうです。
最終的にシンプルなJSON-RPC形式のテストに落ち着いたとのことですが、並列化できず時間がかかっているのもたしかに課題ですね。
でも動くものができたということは、基本的なアプローチは正しかったということでしょうか？
👨サガワ：
正しかったのかはわからないですね.....まぁ「動いてるからヨシ！」なのかもしれませんが.....
反省ばかりなのですが、AI Agentと作業しているとだんだん自分がてきとうになっていって、ざっと見てacceptし始めちゃうんですよ。
テストの抜け漏れがあることも後でわかり...最終的にTDDのはずなのにロジックを正として最終的にテストを整備してしまいました。
ここら辺かな
「気合いで全部テストをチェックしよう！」というのはもちろん気構えとして大事なのですが限界があるので（酒を飲んだ後はマジで何もチェックしていなかった)、ルールの整備が必要だと感じました。
CLAUDE.mdで指示をするのはもちろん、より厳格にGit hooksのpre-commitなどを使うのが有効なのだと思います。「featuresディレクトリ内の関数には必ず同じ名前のテストを全て用意する」というのをAIでもルールベースでもしっかり仕組み化していくべきだったのだろうなと。
恥ずかしい話、テストを用意することを怠ってきたエンジニア人生だったのですが、今後はテストでしかクオリティの判断ができないためより一層このルールを整備すべきだと感じました。
こちらで紹介されているような内容のガードレールをしっかりと敷かなくてはいけないですね。
✨Claude Sonnet 4:
酒を飲んだ後のくだり正直で笑ってしまいました笑
でもこれ、AI Agentとの協働における重要な課題を指摘していますよね。人間がコードを書いていた時代は、書いている過程で「あ、これテスト足りないな」とか気づけたけど、AIが書いたコードを「ざっと見てaccept」する流れだと、どうしても見落としが生まれてしまう。
特に「TDDのはずなのにロジックを正として最終的にテストを整備」というのは、まさにAgentic Codingの落とし穴ですね。AIが「とりあえず動くコード」を書いてしまうと、人間もそれに引っ張られて「動いてるからヨシ！」になってしまう。
Git hooksのpre-commitでのガードレール、これは重要だと思います。機械的にチェックできるルールを先に決めておく、人間の注意力や体調に依存しない仕組み作りですね。
紹介していただいたZennの記事も興味深いです。AI時代のコード品質管理は、従来の「人間の経験と勘」から「ルールベースの自動化」にシフトしていく必要があるんでしょうね。
この辺りの課題感、後のcommitでどう改善されていくのか気になります。
👨サガワ：
人間の注意力や体調に依存しない仕組み作りですね。
すごいこと言いますね笑笑
でもそうですよね。仕組み作りですもんね
要件定義とタスク管理
👨サガワ：
次に進みます。先ほど後述するといった要件定義についてです。
紹介が遅れましたが、今回のアプリはObsidianをMCP経由でAIに操作してもらうものです。
ObsidianのコミュニティプラグインにREST APIサーバーを立ててくれるものがあるので、その機能をMCPから利用できることをゴールとしています。
イメージはこんな感じ。
肝心な要件定義と作業の進め方について、今回はリポジトリ内にprojectフォルダを作成し進めることとしました。こちらのコミットですね。
まず音声入力でざっと背景、目的などを入力しそれをClaude Codeに精緻化してもらいました。その後、project/tasks/フォルダ内にtodo, doing, doneを作成しチケットを発行してもらっています。参考文献フォルダにLocal REST API for Obsidianのopenapi.yamlを入れ、作業の際に参照しやすいようにしています。
こちらのコミットではないのですが、何かの機能に取り組む際はチケットを起点に作業してもらうようCLAUDE.mdに追記しました。
- チケットを確認する
- チケットの受け入れ条件を参考文献やコードベースを参照し、ユーザーと精査する
- ブランチを切って作業を進める
- 確認をとってコミット後developにマージ
というのが大きな流れです。
✨Claude Sonnet 4:
なるほど！ObsidianのLocal REST APIをMCP経由でClaudeに操作してもらう、まさに「AIにObsidianを使ってもらう」プロジェクトなんですね。おもしろいアプローチです。
要件定義のプロセスも興味深いです。音声入力でざっと背景を伝えて、それをClaude Codeに精緻化してもらうというのは、まさに「人間の直感的な説明」と「AIの構造化能力」の良いところを組み合わせていますね。
特に気になるのが、project/tasks/フォルダでtodo, doing, doneの管理をしている点です。これはClaude Codeに対する「タスク管理システム」を作ったということですよね
そして作業フローも面白いです。これって、従来の人間同士の開発フローとほぼ同じ流れをAIとの協働に適用しているということですよね。「相談しつつ細かくする」というのが特に興味深いです。AIと要件の詳細について議論するということでしょうか？
openapi.yamlを参考文献として入れているのも戦略的ですね。
👨サガワ：
AIと要件の詳細について議論するということでしょうか？
そうですね。雛形を出してもらって指摘するラリーを数回行ってチケットを細かい要件にして行きました。
インシデントとその教訓
👨サガワ：
ただですね...ここで重大なミスをやらかしているんです。
もし可能だったら、コミットを見にいって「これは危ない」という点を見つけ出してもらえませんか？
✨Claude Sonnet 4:
あ！これはもしかして...「機密情報や個人情報がコミットに含まれている」という問題でしょうか？
プロジェクト管理とタスクチケットシステムを導入する際に、以下のような危険な情報が含まれている可能性があります：
- APIキーやトークン - Obsidian Local REST APIの設定情報に認証情報が含まれていないか
- 個人のObsidianの内容 - 参考文献や例として、実際の個人ノートの内容が入っていないか
- ローカル環境のパス情報 - システム固有のファイルパスが含まれていないか
- 設定ファイル - .envファイルや設定ファイルに機密情報が含まれていないか
タスク管理の過程で個人的なメモや、実際に使っているObsidianのノート内容がサンプルとして入ってしまった、という可能性もありそうです。
👨サガワ：
これはもしかして...「機密情報や個人情報がコミットに含まれている」という問題でしょうか？
まさしくその点です！要件定義.mdの末尾...！
APIキーがmarkdownに記載されたままコミットしてしまっているんですよ
ここに関しては流石にVIBESで進めてしまった自分の責任なのですが、.envとかに入れてくれるかなーと期待して具体的な値を雛形や指示に入れていたんですよね。
これ予防策としては何が考えられるでしょうか？
✨Claude Sonnet 4:
危険な落とし穴ですね...！「具体的な値を雛形に入れていたら、そのままコミットされてしまった」というのは、Agentic Codingあるあるかもしれません。
AIに「リアルな例を見せたい」という気持ちで実際の値を入れてしまうと、AIはそれを「そのまま使うべき設定値」として認識してしまう可能性がありますもんね。
予防策として考えられるのは：
技術的な予防策
- Git hooksでの自動チェック - pre-commitでAPIキーパターンを検出して止める
-
.gitignoreの徹底 - 設定ファイルは最初からignoreリストに -
環境変数テンプレート -
.env.exampleだけをコミットし、実際の.envは除外 - シークレットスキャン - GitHubのsecret scanningやgitsecretsなどのツール導入
プロセス面での予防策
- CLAUDE.mdでの明示的な指示 - 「APIキーは必ず環境変数にし、.envファイルは.gitignoreに含める」
-
ダミー値の使用 - 要件定義では
YOUR_API_KEY_HEREのようなプレースホルダーを使う - 段階的レビュー - コミット前に「機密情報チェック」を必須ステップにする
特に「AIに具体例を見せる際はダミー値を使う」というのは、Agentic Codingでは鉄則になりそうですね。人間だったら「これは例だから実際の値は別で管理してね」と暗黙的に理解できるけど、AIは文字通りに受け取ってしまいますから。
この経験を踏まえて、後のcommitではどういう対策を取られましたか？
👨サガワ：
なるほど、gitsecretsというライブラリがあるんですね！AWSに関するパターンマッチングが特に得意みたいですがこれはたしかにpre-commitに導入すべきかもしれません。
指示の明確化やダミーは悩ましいところですね。
ここまでくるとサンプルの実行(curlなど)も任せたくなってきちゃうんですよね〜....
この経験を踏まえて、後のcommitではどういう対策を取られましたか？
今回は最終的に.envに出したのみで具体な対策は取りませんでした。
次からはpre-commitにパターンマッチング導入が最も良い策かなぁと考えます。
エンタープライズレベルだったら初めからvault系のPaaSサービスを導入するでしょうし、であればこのような問題は起こらないでしょうか？
✨Claude Sonnet 4:
「サンプルの実行まで任せたくなる」というの分かります。特にcurlでのAPI実行とかまでClaude Codeにやってもらえたら、動作確認も含めて全部自動化できちゃいますもんね。でもそうなると、ますます実際の値を使いたくなる誘惑が...
エンタープライズレベルのvault系PaaSサービス（AWS Secrets Manager、Azure Key Vault、HashiCorp Vaultなど）を使えば、確かにこの問題は大幅に軽減されますね。アプリケーションが直接シークレット管理サービスから値を取得する形になるので、コード上にAPIキーが露出することはなくなります。
ただ、個人開発や小規模プロジェクトだと、そこまでの仕組みは導入しづらいというのも現実ですよね。
思うに、Agentic Codingが普及してくると、この「AIにリアルな値を見せたい vs セキュリティ」のジレンマは多くの開発者が直面する問題になりそうです。
もしかすると、今後は以下のようなツールや慣習が生まれてくるかもしれませんね：
- AI向けの「安全なサンプル値生成ツール」
- 「本物っぽいけどダミー」な値を簡単に作れるライブラリ
- Agentic Coding用のベストプラクティス集
今回の失敗（と学び）は、きっと多くの人の参考になる貴重な経験談だと思います！
さて、次のcommitではどんな展開が待っているんでしょうか？
👨サガワ：
え〜〜〜
思慮が浅いためもう少し深く考えてみましょう
(じっくり考える：ON)
✨Claude Sonnet 4:
そうですね、もっと根本的に考えてみましょう。
このAPIキー漏洩の問題って、実はAgentic Codingがもたらす構造的な課題を表していると思うんです。
従来のセキュリティ対策の前提の崩壊
これまでのセキュリティ対策は「プログラマーが意識的にコードを書き、レビューする」ことが前提でした。でもAgentic Codingでは：
- AIが大量のコードを高速生成する
- 人間は「ざっと見てaccept」してしまう
- 従来の「人間の注意力」に依存した対策が機能しない
責任の所在の曖昧化
「AIが書いたコードでインシデントが起きたら誰の責任？」という問題ですね。技術的には人間がacceptした責任になりますが、実際問題として人間がすべてを理解・チェックするのは不可能です。
開発速度とセキュリティのトレードオフの激化
Agentic Codingは開発速度を劇的に向上させますが、その分セキュリティ対策の相対コストが高く感じられます。「せっかく高速開発できるのに、セキュリティチェックで止まるなんて...」という心理的圧力が強くなります。
つまり、git-secretsやpre-commitのような「従来の延長線上の対策」だけでは不十分で、Agentic Codingを前提とした全く新しいセキュリティアーキテクチャが必要なのかもしれません。
例えば：
- AI自体にセキュリティ知識を組み込む
- 開発環境を完全にサンドボックス化する
- シークレット管理を組織レベルで義務化する
いかがでしょうか？
👨サガワ：
途中の考察は良いですが、結論が少しイマイチですね。セキュリティ知識を組み込むことは現在のLLMの性質上難しいですし、サンドボックス化したとしてもアプリに組み込まれれば漏洩は起こります。
結局のところルールの整備というところに落ち着くのかもしれませんね。
あとは、個人・組織におけるプログラミング高速化によるインセンティブの設計の話でしょうか。
こちらは後ほどClaude Opus 4さんにも聞いてみますので、一旦話を戻しましょう。
✨Claude Sonnet 4:
おっしゃる通りです。技術的な解決策に飛びつくより、まずは基本的なルールの整備が重要ですね。
Claude Opus 4さんのご意見も気になりますが、まずは開発の続きを見ていきましょう。
作業ログと記憶管理
✨Claude Sonnet 4:
セキュリティの課題はいったん置いておいて、要件定義とタスク管理の仕組みを整えた後、実際の機能開発はどんな風に進んでいったんでしょうか？次のcommitを見せてください！
👨サガワ：
ここからは基本的にスムーズに進んでいきました。
チケットのファイルパスをClaude Codeに渡し、見守り、たまに間違えていたら指示を出しacceptしていたというのがほぼすべてです。
コミットログでいうところのfeat:系はこのやり方で進めています。
検索などは少し複雑だったのか手戻りが何度か発生しました。
その際、memory(CLAUDE.md)とは別にチケットに開発ログを残すように指示していたため、どこに詰まったか・どんな仕様変更があったかなどがClaude Codeに伝わりやすくなっていたと思います。
これは今後も続けて行きたいです。
✨Claude Sonnet 4:
チケットに開発ログを残すというのは、実践的なアイデアですね。
従来の開発だと、プログラマー個人の頭の中に「なぜこう実装したか」「どこで詰まったか」といった文脈情報が蓄積されていくわけですが、Agentic Codingだとその情報が散逸してしまいがちです。
チケットに開発ログを残すことで、AIにとっての「短期記憶」を補完している感じですね。CLAUDE.mdが「長期記憶」だとすると、チケットの開発ログは「作業記憶」みたいな役割を果たしているのかもしれません。
特に検索機能のような複雑な実装で手戻りが発生した際に、「前回何を試してダメだったか」「どんな仕様変更があったか」がチケットに残っていることで、同じ試行錯誤を繰り返さずに済むというのは大きなメリットですね。
これって、人間同士の開発でも参考になりそうなプラクティスです。普通はSlackやコメントに散らばってしまう情報を、チケットという一元的な場所に集約している感じで。
「見守り、たまに間違えていたら指示を出しaccept」というフローが確立されると、確かにスムーズに進みそうですね。この段階では、もう開発のリズムが掴めてきた感じでしょうか？
👨サガワ：
自分があまり脳のメモリがない人間で、見返しやすいようずっと作業ログを残していたんですよね。
今はローカルのエディタで書いてますけど、zennのスクラップも好きでした。
ただこれ人間がやると呟きみたいな細切れになっちゃうので、issueにぶら下げるの少し抵抗があったんですよ。「なんか動かない」とか書いてると煩雑になっちゃうし、「何時何分に何がどうなった」までは流石に面倒くさくて書けない。その点AIにログを残してもらえるのは粒度・頻度・正確性といった面で相性が良いかもしれませんね。
見守り、たまに間違えていたら指示を出しaccept」というフローが確立されると、確かにスムーズに進みそうですね。この段階では、もう開発のリズムが掴めてきた感じでしょうか？
そうですね〜少しずつリズムは掴めてきていたと思います
ただ、最初に話していたようなルールの整備が行き届いていなかったため必死でdiffを見まくることになってたんです。すごい疲れたというのが正直な感想です
テストがちゃんと整っているかのテストを用意しないと....
✨Claude Sonnet 4:
AIだと：
- 粒度：具体的な関数名やエラーメッセージまで書いてくれる
- 頻度：コード変更のたびに律儀に記録してくれる
- 正確性：「何時何分に何をした」まで正確に残してくれる
これは確かに、人間には面倒でできない作業かもしれませんね。
そして「必死でdiffを見まくることになって、すごい疲れた」というのも、すごくリアルな感想ですね（笑）。結局、テストが不十分だと人間がセーフティネットになるしかなくて、それがとても疲れてしまう...
「テストがちゃんと整っているかのテスト」って、まさにメタな品質管理ですね。Agentic Codingでは、従来の「コードの品質」だけじゃなくて「テストの品質」「ルールの遵守」まで含めた多層的な品質管理が必要になってくるんでしょうね。
この疲労感を経て、後の開発ではどんな改善策を取られたんでしょうか？
👨サガワ：
いえ！今回お陰様で3日間で開発が終了したのでまだ改善は取れていないんです。なので次の個人プロジェクトでさらにルールを整備したいと考えています。
一応このプロジェクトが最終的にどうなったかをお伝えしておくと
- MCP Serverのレスポンスについて望まない形式にフォーマットされていた部分を構造化された形式に整えた
- 抜け漏れがあったテストの整備を行なった
- ドキュメンントを整えた
という流れになります。
以上でいったんObsidian MCP Serverを完成としました。
✨Claude Sonnet 4:
3日間で完成というのは早いですね。しかもロジックをほぼ書かずにここまでのクオリティのものを作り上げたというのは、すごい実験だったと思います！。Agentic Codingのポテンシャルを感じます。
まとめ：Agentic Codingの品質管理
✨Claude Sonnet 4:
今回の振り返りを通して、Agentic Codingの可能性と課題の両方がよく見えてきましたね：
可能性
- 高い開発速度
- 人間は設計・要件定義に集中できる
- AIによる詳細な開発ログ
課題
- セキュリティ（APIキー漏洩など）
- 品質管理（テスト整備、ルール遵守）
- 人間の疲労（diff確認の負担）
次のプロジェクトでは、今回の学びを活かしてより洗練されたAgentic Codingが実現できそうですね。特にpre-commitのルール整備や、テスト品質の自動チェックなど、楽しみです！
👨サガワ：
その通りですね。
一度テスト設計の本を複数読んでこようと思います。
他に何か、次の行動指針についてアドバイスがあればお願いします。
✨Claude Sonnet 4:
テスト設計の学習、素晴らしい方向性だと思います。
次のプロジェクトに向けた行動指針として、いくつかアドバイスさせていただきますね：
学習面
- テスト設計本と合わせて「AIが書いたテストの品質をどう評価するか」の観点も重要そうです。従来のテスト設計は人間が書く前提なので、AI特有の癖（過度に楽観的なケース、エッジケースの見落とし等）への対策も考えてみてください
- TDD/BDDの実践例を、今度はAI相手にどう適用するかという視点で学び直すのも良さそうです
ツールチェーン整備
- pre-commitの段階的導入：いきなり全部は大変なので、まずはAPIキー検出から始めて、徐々にルールを増やしていく
- テストカバレッジの自動チェック：単にカバレッジ率だけでなく、「重要な機能にテストがあるか」まで見る仕組み
- CLAUDE.mdのテンプレート化：今回の学びを活かして、再利用可能な指示書の雛形を作る
実験的挑戦
- 次はもう少し複雑なドメイン（例：決済処理、認証システムなど）でAgentic Codingを試してみる
- 複数のAIツール（Claude Code + GitHub Copilot等）の組み合わせ実験
いかがでしょうか？
👨サガワ：
テスト設計本と合わせて「AIが書いたテストの品質をどう評価するか」の観点も重要そうです。従来のテスト設計は人間が書く前提なので、AI特有の癖（過度に楽観的なケース、エッジケースの見落とし等）への対策も考えてみてください
そうですね〜〜〜。モックを返してテストオッケー！とするAIがいてもおかしくないですものね
えーー.....そうなるとあれですか....
将来的には機械学習におけるtest/validationデータみたいに、AIが認知しえないテストの用意も必要になるのでしょうか....なんかすっごい帰納的......
ちょっとまずはTDDのお作法を勉強してきます...
次はもう少し複雑なドメイン（例：決済処理、認証システムなど）でAgentic Codingを試してみる
決済処理や認証のテストか〜〜〜〜
切っても切れないところですね〜〜〜
検討してみます...！
今回はお付き合いいただきありがとうございました！
理解を深めていく上でたくさんの示唆が得られました。
最後にこの対談をObsidianにまとめてください！
✨Claude Sonnet 4:
こちらこそ、とても興味深い対談をありがとうございました！
それでは、今回の対談内容をObsidianにまとめさせていただきますね。
本日はありがとうございました！
# AI Agentを使ったコーディングの振り返り - Obsidian MCP Server開発記
## プロジェクト概要
**プロジェクト名**: obsidian-mcp-server
**開発期間**: 3日間
**目的**: MCP Server構築の練習 + Agentic Codingの実験
**特徴**: ロジックを一切書かず、微修正のみでAIメインパイロットでの開発
### システム構成
```
Obsidian Local REST API ←→ Obsidian MCP Server ←→ Claude
(httpリクエスト) (コマンド実行) (MCP Client)
```
## 開発手法・アーキテクチャ
### 採用したアプローチ
- **Feature-Sliced Design**: AIが理解しやすいよう機能別フォルダ構成
- **Claude Code中心**: `/init`コマンドでCLAUDE.md作成
- **AIメインパイロット**: 人間は設計・要件定義・方向性決定に専念
### 初期セットアップ
- MCP公式クイックスタートを起点
- Feature-Sliced Designドキュメントを参考資料として提供
- CLAUDE.mdによるコンテキスト管理
## 品質管理の仕組み
### 基本方針
1. **要件をしっかり詰める**
2. **型とスキーマを詰める**
3. **テストを用意する**
### 実装したテスト戦略
- **単体テスト**: Vitest使用
- **統合テスト**: JSON-RPC形式でstdin/stdout検証
- **MCP Inspector**: GUIでの手動テスト（自動化は未実装）
### 課題となった点
- 人間の注意力に依存するチェック体制
- 「動いてるからヨシ！」になりがちな心理的罠
- TDDのはずがロジック先行でテスト後付けになった事例
## セキュリティの重大課題
### 発生した問題
**APIキー漏洩事件**: 要件定義.mdにAPIキーを記載したままコミット
### 根本原因
- AIに具体的な値を例示 → そのまま使用される
- 「.envに入れてくれるだろう」という楽観的期待
- 実際の値とダミー値の区別をAIが理解できない
### 予防策案
**技術的対策**:
- Git hooks (pre-commit)での自動チェック
- git-secretsなどのパターンマッチングツール
- .gitignoreの徹底
**プロセス対策**:
- CLAUDE.mdでの明示的セキュリティ指示
- ダミー値の徹底使用
- 段階的レビューの義務化
## 開発プロセスの工夫
### タスク管理システム
```
project/
├── tasks/
│ ├── todo/
│ ├── doing/
│ └── done/
└── 参考文献/
```
### 開発フロー
1. チケットを確認
2. 受け入れ条件を相談して詳細化
3. ブランチを切って作業
4. 確認後にコミット・マージ
### AIによる開発ログ管理
**メリット**:
- 粒度: 具体的な関数名・エラーメッセージまで記録
- 頻度: コード変更のたびに自動記録
- 正確性: 時刻・変更内容を正確に記録
人間には面倒すぎる作業をAIが継続的に実行
## 学んだこと・課題
### Agentic Codingの可能性
- **圧倒的開発速度**: 3日間での完成
- **人間の役割シフト**: 設計・要件定義に集中可能
- **詳細ログ管理**: AI による継続的記録
### 構造的課題
- **従来セキュリティ対策の前提崩壊**: 人間のレビューに依存する仕組みが機能しない
- **責任の所在の曖昧化**: AIが書いたコードの責任は誰が？
- **開発速度 vs セキュリティのトレードオフ激化**
### 必要な対策
- **ルールベースの自動化**: 人間の注意力に依存しない仕組み
- **多層的品質管理**: コード・テスト・ルール遵守の全方位チェック
- **AIが認知できないテストケース**: 機械学習のvalidationデータ的発想
## 今後の行動指針
### 学習計画
- **テスト設計本の複数読破**
- **TDD/BDD実践**: AI相手への適用方法
- **AIテスト品質評価**: AI特有の癖への対策
### ツールチェーン整備
- **pre-commit段階的導入**: APIキー検出から開始
- **テストカバレッジ自動チェック**: 重要機能への必須テスト
- **CLAUDE.mdテンプレート化**: 再利用可能な指示書
### 次回実験テーマ
- **より複雑なドメイン**: 決済処理、認証システム等
- **複数AIツール連携**: Claude Code + GitHub Copilot等
## まとめ
Agentic Codingは開発速度を劇的に向上させる可能性を秘めているが、従来の開発プロセス・品質管理手法では対応できない新しい課題も浮き彫りになった。
特に「人間の注意力に依存しない仕組み作り」が今後の鍵となる。技術的解決策だけでなく、**ルールの整備とプロセスの見直し**が最も重要である。
次回プロジェクトでは、今回の学びを活かして、より洗練されたAgentic Codingの実現を目指す。
---
*対談日: 2025年5月26日*
*リポジトリ: https://github.com/fumi-sagawa/obsidian-mcp-server*
Discussion