🤖

Claude Code不要！プロンプトエンジニアリングでどこまで開発できる？

2025/07/26に公開

 はじめに「Claude Codeを使ってみたいけど、追加料金が...」

「プロンプトエンジニアリングだけで、どこまで実用的な開発ができるの？」
そんな疑問を抱えている個人開発者の方、いらっしゃいませんか？
私は普段AWSインフラエンジニアとして働きながら、プライベートではRustでのOSS開発に挑戦しています。これまでPythonでのスクリプト実装が中心でしたが、今年からRustとGoの学習に力を入れています。
今回、月額$20のClaude Proのみを使い、プロンプトエンジニアリングだけで実用的なRust CLIツールを開発するという検証プロジェクトを開始しました。
この記事では、その第1回としてプロジェクトの全体像と初期実装の成果をお届けします。

 なぜClaude Codeを使わないのか？
 コスト問題への現実的なアプローチClaude Codeは確かに魅力的なツールですが、個人開発者にとってコストは重要な検討事項です。
現在の課金状況:
✅ Claude Pro: $20/month
❓ Claude Code: 追加料金

→ 月額$20で、どこまでできるかを検証したい

 プロンプトエンジニアリングスキルの汎用性専用ツールではなく汎用的なAIチャットを使いこなすスキルは、将来的により広い場面で活用できると考えています。

 技術的挑戦としての価値「本当にAIチャットだけで実用的な開発ができるのか？」という純粋な技術的興味もあります。

 プロジェクト概要：docka - TUI Docker管理ツール
 なぜこのプロジェクトを選んだか開発対象として選んだのは、dockaというTUI（Text User Interface）ベースのDocker管理ツールです。
# こんな感じのfzf風インターフェースを目指しています
$ docka
┌─ Containers ────────────────────────┐
│ ▶ web-server     [Running]  80:80   │
│   database       [Stopped]  -       │
│   redis-cache    [Running]  6379    │
└─────────────────────────────────────┘
選択理由:

実用性: 日常業務で実際に使えるツール

技術的挑戦: Rust + TUI + Docker APIの組み合わせ

複雑度: プロンプトエンジニアリングの限界をテストできる

検証可能性: 明確な完成形とKPI設定が可能

 技術スタック
Rust: パフォーマンスとメモリ安全性

ratatui: TUIフレームワーク

bollard: Docker API クライアント

tokio: 非同期ランタイム

 プロジェクトの制約条件【制約】
🔒 AI支援: Claudeのみ（月額$20プラン内）
🔒 期間: 4週間でMVP完成
🔒 品質基準: Clippy警告ゼロ、テストカバレッジ70%以上
🔒 パフォーマンス: 起動3秒以内、メモリ200MB未満

 検証方法論（他記事との差別化ポイント）単なる「AI使ってみた」記事ではなく、定量的な検証を行います。

 測定指標の設定
 コスト効率時間単価 = 月額$20 ÷ 実開発時間
開発効率向上率 = (予想時間 - 実際時間) ÷ 予想時間
ROI = 時間節約価値 ÷ 月額料金

 開発スピードフェーズ別開発時間（要件→設計→実装→テスト）
プロンプト作成・改善時間
AI相談回数とその効果

 コード品質Clippy警告数（目標：ゼロ）
テストカバレッジ（目標：70%以上）
循環的複雑度

 学習効果プロンプト試行錯誤回数
スキル習得時間
技術理解度の向上

 BDD × AI駆動開発のワークフローライブコーディング的にならないよう、**BDD（振る舞い駆動開発）**を採用します。
Phase 1: 要件定義・分析
├─ ユーザーストーリー作成 + Claude相談
├─ 受け入れ条件定義 + AI網羅性チェック
└─ Gherkinシナリオ生成

Phase 2: 設計・アーキテクチャ
├─ システム設計 + Claude技術相談
├─ Rustベストプラクティス確認
└─ テスト戦略策定

Phase 3: 実装
├─ テストファースト開発
├─ AI支援コード生成
└─ 継続的リファクタリング

 Week 1実装結果：Docker接続基盤完成
 達成した成果Week 1（4日間）で、以下を完全実装しました：
✅ Docker接続基盤完全実装（4タスク完了）
✅ 品質指標100%達成
   - Clippy警告: 0個
   - 単体テスト: 61個（100%通過）
   - 統合テスト: 15個（実Docker環境）
✅ 最新技術対応
   - OpenAPI生成型API使用
   - Rustベストプラクティス完全適用

 実装内容の詳細
 1. プロジェクト基盤（2.5時間）カスタムエラー型システムの構築から開始しました。
// src/error/app_error.rs
#[derive(Error, Debug)]
pub enum DockaError {
    #[error("Docker connection failed: {0}")]
    DockerConnection(String),

    #[error("Container not found: {0}")]
    ContainerNotFound(String),

    #[error("Invalid container ID: {0}")]
    InvalidContainerId(String),

    // 12種類のエラーバリアント...
}

pub type DockaResult<T> = Result<T, DockaError>;
AI相談効果: エラー設計のベストプラクティスを即座に習得

 2. ドメインエンティティ（4時間）Domain-Driven Designに基づいたエンティティ設計を行いました。
// src/domain/entities/container.rs
#[derive(Debug, Clone, PartialEq)]
pub struct Container {
    id: ContainerId,
    name: String,
    image: String,
    status: ContainerStatus,
    created: DateTime<Utc>,
}

impl Container {
    pub fn can_start(&self) -> bool {
        matches!(self.status, ContainerStatus::Exited { .. } | ContainerStatus::Created)
    }

    pub fn can_stop(&self) -> bool {
        matches!(self.status, ContainerStatus::Running)
    }
}
特徴:
Strong Typing（ContainerId型）による型安全性
Builder Patternによる安全なオブジェクト構築
ビジネスロジックの適切な封じ込め

 3. Repository Pattern（3.5時間）テスタビリティを考慮したRepository Pattern実装。
// src/domain/repositories/docker_repository.rs
#[async_trait]
pub trait DockerRepository: Send + Sync {
    async fn list_containers(&self) -> DockaResult<Vec<Container>>;
    async fn get_container(&self, id: &ContainerId) -> DockaResult<Container>;
    async fn start_container(&self, id: &ContainerId) -> DockaResult<()>;
    async fn stop_container(&self, id: &ContainerId) -> DockaResult<()>;
    async fn remove_container(&self, id: &ContainerId, force: bool) -> DockaResult<()>;
}
AI相談効果: 3人の専門家による多角的なコードレビューで設計品質向上

 4. Docker API統合（5時間）bollardクライアントを使用したDocker API連携の実装。
// src/infrastructure/docker/bollard_client.rs
pub struct BollardDockerRepository {
    client: Arc<Docker>,
}

#[async_trait]
impl DockerRepository for BollardDockerRepository {
    async fn list_containers(&self) -> DockaResult<Vec<Container>> {
        let options = ListContainersOptions::<String> {
            all: true,
            ..Default::default()
        };

        let containers = self.client
            .list_containers(Some(options))
            .await
            .map_err(|e| DockaError::DockerConnection(e.to_string()))?;

        // bollard → Domain entity変換
        containers.into_iter()
            .map(|c| self.map_to_domain_container(c))
            .collect()
    }
}
技術的チャレンジ:
deprecated API → OpenAPI生成型への移行
実Docker環境での15個の統合テスト
Clippy警告44個の段階的解決

 プロンプトエンジニアリングの効果と学び
 AI相談実績総相談回数: 38回（4日間）
平均問題解決時間: 15分以内
効果的だった相談パターン:
✅ エラー設計のベストプラクティス確認
✅ 3人専門家によるコードレビュー
✅ Docker標準準拠の実装方針決定
✅ 44個のClippy警告の段階的解決

 効果的なプロンプトパターン
 1. 段階的詳細化❌ 悪い例: "Docker API使ってRustでコンテナ管理ツール作って"

✅ 良い例:
"Rustでbollardクレートを使用してDocker API連携を実装します。
DockerRepository traitの以下のメソッドを実装してください:
async fn list_containers(&self) -> DockaResult<Vec<Container>>

制約:
- 最新のOpenAPI生成型を使用
- エラーハンドリングはDockaErrorを使用
- 実装前に使用するAPIの説明をお願いします"

 2. 専門家ペルソナ活用"3人の専門家（プロダクトマネージャー、Docker使用者、開発エンジニア）が
以下のコードをレビューしていると想像してください。
それぞれの観点から改善提案をお願いします。"

 3. 品質基準の明確化"以下の要件を満たすコードを実装してください:
- Clippy警告ゼロ
- 適切なドキュメントコメント
- 単体テスト付き
- エラーハンドリング完備"

 学習効果Rustベストプラクティスの即座習得:
Repository Pattern等の設計パターン適用

async_trait、Arc<T>等の適切な使用法
Clippy ルールの理解とコード品質向上
Docker API最新仕様への即応:
bollard v0.17の最新機能活用
deprecated APIからの移行手法

 初期段階でのコスト効率分析
 Week 1実績実装時間: 15時間
月額コスト: $20
時間単価: $1.33/時間

AI相談効果: 問題解決時間50%短縮（推定）
学習効率: 通常3倍速でRust技術習得（体感）

 従来手法との比較（推定）【AI支援なしの場合（推定）】
- 実装時間: 25-30時間
- 学習時間: 追加10-15時間
- 品質債務: Clippy警告、テスト不備

【AI支援ありの実績】
- 実装時間: 15時間
- 学習効果: 並行習得
- 品質債務: ゼロ（リアルタイム解決）

→ 時間効率40-50%向上

 AI駆動開発で気づいた点
 良かった点✅ 設計相談での多角的視点獲得: 3人専門家による包括的レビュー

✅ エラー解決の迅速性: 平均15分以内での問題解決

✅ ベストプラクティスの即座適用: 学習と実装の同時進行

✅ 品質債務のリアルタイム解決: 技術的負債の蓄積防止

 注意が必要な点⚠️ プロンプト設計の重要性: 曖昧だと的外れな回答

⚠️ 段階的実装の徹底: 一度に複雑すぎると破綻

⚠️ 検証の必要性: AI提案も必ず動作確認が必要

 今後の展開予告
 Week 2-4の計画Week 2: TUI実装
- ratatuiによる画面表示
- キーボードナビゲーション
- 非同期UI更新

Week 3: 非同期Actor実装
- UIブロック回避
- パフォーマンス最適化
- メモリ使用量200MB以下達成

Week 4: コア操作機能
- コンテナ起動・停止・削除
- エラーハンドリング強化
- E2Eテスト実装

 連載で追跡する指標
開発効率: 週ごとの実装速度変化

学習曲線: Rust/TUI技術の習得進度

品質維持: Clippy警告ゼロの継続性

プロンプト進化: 効果的なプロンプトパターンの蓄積

 読者の皆様へ
 透明性のコミットこの連載では以下を約束します：

週次進捗: 毎週の開発状況を包み隠さず公開

生データ公開: 時間、コスト、品質指標の実数値

失敗も共有: うまくいかなかった点と改善方法

プロンプト公開: 効果的だったプロンプトの実例

 記事シリーズの予定
第1回（今回）: プロジェクト開始・基盤実装 ✅

第2回: TUI実装とユーザビリティ

第3回: 非同期処理とパフォーマンス

第4回: 完成・総合評価

番外編: プロンプトライブラリ公開

 読者の皆様との交流もし類似のチャレンジをされている方、プロンプトエンジニアリングのTipsをお持ちの方がいらっしゃいましたら、ぜひコメントで情報交換させてください！

 まとめWeek 1の検証結果として、プロンプトエンジニアリングを活用したAI駆動開発の有効性を実感しています。
主な成果:
15時間で堅牢なDocker API基盤を構築
Clippy警告ゼロ、テスト76個の高品質実装
時間効率40-50%向上（推定）
Rust技術の効率的習得
次回はTUI実装編として、ratatuiとcrosstermを使った実際のインターフェース構築過程をお届けします。fzf風の直感的操作を実現する過程で、どんな課題があり、どう解決していくのか。
更新予定: 2025年8月第1週
最後まで読んでいただき、ありがとうございました！

はじめに

なぜClaude Codeを使わないのか？

コスト問題への現実的なアプローチ

プロンプトエンジニアリングスキルの汎用性

技術的挑戦としての価値

プロジェクト概要：docka - TUI Docker管理ツール

なぜこのプロジェクトを選んだか

技術スタック

プロジェクトの制約条件

検証方法論（他記事との差別化ポイント）

測定指標の設定

コスト効率

開発スピード

コード品質

学習効果

BDD × AI駆動開発のワークフロー

Week 1実装結果：Docker接続基盤完成

達成した成果

実装内容の詳細

1. プロジェクト基盤（2.5時間）

2. ドメインエンティティ（4時間）

3. Repository Pattern（3.5時間）

4. Docker API統合（5時間）

プロンプトエンジニアリングの効果と学び

AI相談実績

効果的なプロンプトパターン

1. 段階的詳細化

2. 専門家ペルソナ活用

3. 品質基準の明確化

学習効果

初期段階でのコスト効率分析

Week 1実績

従来手法との比較（推定）

AI駆動開発で気づいた点

良かった点

注意が必要な点

今後の展開予告

Week 2-4の計画

連載で追跡する指標

読者の皆様へ

透明性のコミット

記事シリーズの予定

読者の皆様との交流

まとめ

Discussion