はじめに
「AIアシスト開発」という言葉が定着して久しいが、2026年に入ってからその使われ方が明らかに変わってきた。単にコードを補完させるだけでなく、UIデザインの初稿を生成させたり、データベースのMCPサーバーと繋いで自律的にクエリを書かせたりと、開発ワークフロー全体に組み込まれるようになってきている。
今回は直近のトレンドを軸に、Claude Codeを中心としたAIアシスト開発の現実を整理してみる。理想論ではなく、実際に運用してみて引っかかったことや、ツール選択の判断軸として参考になった知見をまとめた。
FigmaよりClaudeでデザインする人が増えている
Hacker Newsで話題になっていたのが「I design with Claude more than Figma now」という投稿だ。これは一部のパワーユーザーに限った話ではなく、特にプロトタイプ段階では実際に起きている変化だと感じる。
Figmaは「完成品を作る」ツールで、コンポーネントの整合性管理や共同編集に強みがある。一方、Claude（とくにClaudeのHTMLレンダリング能力）は**「アイデアを素早く形にする」フェーズで圧倒的に速い**。
Zennでも「Claude Codeで仕様書をMarkdownとHTMLで書き比べた」という記事が出ていたが、HTMLで仕様書を書いたほうがClaudeの出力品質が上がるという知見は面白い。Anthropicの技術ブログ「Using Claude Code: The unreasonable effectiveness of HTML」でも触れられているように、HTMLはUIの意図を構造的に伝えやすく、Claudeのコンテキスト理解と相性がいい。
実務での活用イメージ：
<!-- こういう仕様書HTMLをClaudeに渡すと精度が上がる -->
<section id="user-profile">
<h2>ユーザープロフィール画面</h2>
<ul>
<li>アバター画像（丸形、64px）</li>
<li>表示名（最大20文字、編集可）</li>
<li>自己紹介文（最大140文字、任意）</li>
</ul>
<note>モバイルファーストで実装。Tailwind CSS使用。</note>
</section>
Markdownで同じ内容を書くよりも、要素の階層関係と制約が明確になる。「なんとなくHTMLのほうが賢そうに答える」という感覚の正体はここにある。
MCPサーバーにexecute_sqlを渡してはいけない理由
dev.toで「Preventing context bloat and agent loops in database MCP servers」という記事が公開されており、MCP設計のアンチパターンとして参考になった。
要点はシンプルで、汎用的なexecute_sqlツールをエージェントに渡すのは危険だということだ。
理由は二つある：
-
コンテキスト爆発：エージェントが探索的にSQLを実行すると、巨大な結果セットがコンテキストに積み上がっていく。数回のループで10万行のレスポンスがコンテキストに乗ることも珍しくない。
-
エージェントループ：「何を実行すべきか」の判断を毎回エージェントに委ねると、同じクエリを繰り返したり、エラーを無限に修正しようとするループに陥りやすい。
対策として有効なのは、目的に特化したツールを定義することだ：
# 汎用ツール（避けるべき）
@mcp.tool()
def execute_sql(query: str) -> list[dict]:
return db.execute(query)
# 目的特化ツール（推奨）
@mcp.tool()
def get_user_count_by_plan(plan: str, limit: int = 10) -> dict:
"""プラン別ユーザー数を取得。limitは最大100。"""
result = db.execute(
"SELECT COUNT(*) as cnt FROM users WHERE plan = ? LIMIT ?",
[plan, min(limit, 100)]
)
return {"plan": plan, "count": result[0]["cnt"]}
これはMCPに限らず、LLMにツールを渡す設計全般に言える原則だ。「何でもできる」ツールは、エージェントが迷子になる原因になる。ツールの責任範囲を絞ることで、コンテキストの消費も動作の予測可能性も改善する。
Claude CodeとCodexの設計思想の違い
Zennで「Claude CodeとCodexを使い比べて見えた設計思想の違い」という記事が注目を集めていた。筆者はClaude Code一本で来たエンジニアがOpus 4.7の品質に不満を感じてCodexに試乗し、その振る舞いの違いから設計哲学を考察したものだ。
観察されていた違いを簡単に整理すると：
| 観点 | Claude Code | Codex |
|---|---|---|
| ファイル操作の積極性 | 積極的に複数ファイルを横断 | 指示されたファイルに集中 |
| エラー時の振る舞い | 自律的に修正を試みる | ユーザーに確認を返す |
| コンテキスト管理 | 長い会話でも継続 | セッションをコンパクトに保つ |
どちらが「良い」かは用途によるが、自律性が高い = 意図しない変更が起きやすいというトレードオフは常に存在する。Claude Codeで大規模なリファクタを依頼すると、関連ファイルを勝手に書き換えることがある。これが「賢い」とも「怖い」とも感じる人がいるのはそういう理由だ。
実務的な使い分けとしては、仕様が固まっている実装タスクはClaude Code、既存コードへの局所的な変更はCodex、という判断軸が一つの答えになりそうだ。
Rustのエラーハンドリングで地味に踏む罠
Zennに「Rustでエラー原因をsourceとDisplayの両方に書いてはいけない理由」という記事も出ていた。Rustのエラー設計ではthiserrorを使うことが多いが、このパターンに気をつける必要がある：
// NG: DisplayとsourceにどちらもDB接続エラーを含めている
#[derive(Error, Debug)]
#[error("DB接続に失敗しました: {0}")] // ← ここにsourceの内容を書いてしまっている
pub struct AppError(#[source] DbError);
// OK: DisplayはAppError自身の説明に留める
#[derive(Error, Debug)]
#[error("DB接続に失敗しました")]
pub struct AppError(#[source] DbError);
anyhowなどのエラーレポーターはsource()チェーンを自動で辿ってすべての原因を表示する。Displayにも同じ内容を書くとエラーメッセージが二重に出力される。地味だが、ログ調査時に混乱する原因になる。
まとめ
AIアシスト開発は「便利なオートコンプリート」の時代を完全に抜けた。デザインの初稿生成、仕様書フォーマットの工夫、MCPサーバーの設計指針、ツール選択の哲学——それぞれ実運用の文脈で具体的な知見が蓄積されてきている。
特にMCPのツール設計は、これからLLMを業務システムに繋ぐ人が必ず直面するテーマだ。「とりあえず汎用SQLツールを渡す」という最初の一手を踏み留まれるかどうかで、後の運用コストが大きく変わる。
ツールが増えるほど、判断の質が問われる局面も増える。今のうちに設計の勘所を押さえておくのが、この時期の正しい投資だと思う。