📊
オレオレClineプロンプトエンジニアリング20250225
はじめに
数日Clineを触ってみましたが、画像生成AIと同じようにやりこめばやりこむほど時間が足りなくなるコンテンツだということがわかったので、2025/02/25時点で最も効率の良い私のやり方をシェアして、また様子見したいと思います。
そもそもAIは仕事を減らすためにあってほしいので、AIを使うために仕事が増えるのは避けたいところです。
チャート法
夕食を食べながらとあるRTA動画を視聴していたところ、こんな言葉を見かけました。
チャートにちゃーんと書いておきましょう
これだ！ とひらめいたのがchart.mdを用意して、それをClineに読み込ませる方法でした。
1. 推論モデルでチャートを作成する
まずChatGPTのo3-miniのような推論モデルに以下プロンプトを入力します。
GoでSNSを開発する手順書を作成してください。
Markdownで4個の大分類、16個の中分類、64個の小分類に分けて説明してください。
各分類には番号をふってください。
小分類の下位にMarkdownの番号リストで手順を記載してください。
開発とテスト以外の手順を記載しないでください。
必要に応じて以下プロンプトも追加します。
また、下記ライブラリを使用してください。
* github.com/labstack/echo
* github.com/mattn/go-sqlite3
* github.com/joho/godotenv
するとMarkdown形式で手順書を出力してくれるので、これをchart.mdとして保存します。
手順書全文（8000文字）
chart.md
# 1. 開発環境の構築
## 1.1 Goのインストールと設定
### 1.1.1 Goのダウンロード
1. オフィシャルサイト（https://golang.org/dl/）から最新のGoパッケージをダウンロードする。
2. ダウンロードしたパッケージをローカル環境に保存する。
3. インストーラを実行し、Goをインストールする。
### 1.1.2 環境変数の設定
1. GOROOTおよびGOPATHの値を設定する。
2. PATH環境変数にGoのbinディレクトリを追加する。
3. シェルを再起動して環境変数の設定を反映させる。
### 1.1.3 Goバージョン確認
1. ターミナルを起動する。
2. `go version`コマンドを実行する。
3. 表示されたバージョンが正しいことを確認する。
### 1.1.4 IDE設定の最適化
1. 好みのIDE（例: VSCode）をインストールする。
2. Go用の拡張機能（例: gopls）を追加する。
3. 自動補完・自動フォーマット機能を有効化する。
## 1.2 プロジェクトの初期化と依存管理
### 1.2.1 プロジェクトディレクトリ作成
1. 新規プロジェクト用のディレクトリを作成する。
2. 開発用のサブディレクトリ（例: cmd、pkg、internal）を整備する。
3. READMEファイルにプロジェクト概要（開発目的のみ）を記述する。
### 1.2.2 go.modの初期化
1. プロジェクトルートで`go mod init [モジュール名]`を実行する。
2. 生成されたgo.modファイルの内容を確認する。
3. 不要な依存が無いかチェックする。
### 1.2.3 Git管理の開始
1. プロジェクトディレクトリで`git init`を実行する。
2. Go関連の除外パターンを記述した.gitignoreファイルを作成する。
3. 初期状態のファイルをステージングする。
### 1.2.4 初期コミットの作成
1. 変更内容を`git add .`でステージングする。
2. 適切なコミットメッセージで`git commit -m "Initial commit"`を実行する。
3. コミット履歴を確認して初期状態を確定する。
## 1.3 必要ライブラリのインストール
### 1.3.1 Echoライブラリのインストール
1. ターミナルで`go get github.com/labstack/echo/v4`を実行する。
2. インストールログでエラーがないことを確認する。
3. go.modにEchoライブラリが追加されたことをチェックする。
### 1.3.2 go-sqlite3ライブラリのインストール
1. ターミナルで`go get github.com/mattn/go-sqlite3`を実行する。
2. インストール完了のメッセージを確認する。
3. go.modにSQLite3ドライバが反映されているかチェックする。
### 1.3.3 godotenvライブラリのインストール
1. ターミナルで`go get github.com/joho/godotenv`を実行する。
2. インストール完了を確認する。
3. 依存管理ファイルにgodotenvが追加されたか確認する。
### 1.3.4 依存ライブラリのバージョン確認
1. `go list -m all`を実行し、依存ライブラリ一覧を表示する。
2. 各ライブラリのバージョン情報を確認する。
3. 必要に応じてアップデートの検討を行う。
## 1.4 コーディング規約と開発ツールの設定
### 1.4.1 GoLintの設定
1. GoLintツールをインストールする。
2. プロジェクト内にLintルールの設定ファイルを追加する。
3. コードチェックを実行し、Lintエラーを確認する。
### 1.4.2 コードフォーマッタの導入
1. `gofmt`または`goimports`をプロジェクトに導入する。
2. IDEと連携し自動フォーマットを有効化する。
3. コード整形の結果を確認し、フォーマットが適用されているかチェックする。
### 1.4.3 静的解析ツールの導入
1. 静的解析ツール（例: govet, staticcheck）をインストールする。
2. 解析ツール用の設定ファイルを作成する。
3. ツールを実行し、警告内容を確認する。
### 1.4.4 テストランナーの設定
1. Goの標準テストフレームワーク（testingパッケージ）の利用準備を行う。
2. テスト実行用のスクリプト（例: Makefileまたはシェルスクリプト）を作成する。
3. テスト実行が自動化されるようCIツールと連携する設定を追加する。
---
# 2. 機能の実装
## 2.1 Echoを使ったHTTPサーバーの実装
### 2.1.1 Echoの基本設定
1. Echoのインスタンスを生成するコードを記述する。
2. サーバー起動用のエントリーポイントを作成する。
3. 起動時に必要な基本設定（ポート番号等）を反映する。
### 2.1.2 ミドルウェアの追加
1. ロギング、リカバリーなどの基本ミドルウェアを設定する。
2. 各ミドルウェアの順序を決定する。
3. ミドルウェアの動作確認用の簡易テストを実施する。
### 2.1.3 ルーティングの定義
1. 各APIエンドポイントのルートを定義する。
2. 各ルートに対してハンドラ関数を割り当てる。
3. URLパラメータやクエリパラメータの取得ロジックを実装する。
### 2.1.4 エラーハンドリングの実装
1. 共通のエラーハンドリングミドルウェアを実装する。
2. エラーメッセージのフォーマットを統一する。
3. 異常時のHTTPステータスコードを適切に設定する。
## 2.2 SQLite3を使ったデータベース接続の実装
### 2.2.1 SQLiteデータベースファイルの作成
1. プロジェクト内にSQLite用のデータベースファイルを作成する。
2. ファイルパスを環境変数で管理できるよう設定する。
3. データベースファイルのアクセス権限を適切に設定する。
### 2.2.2 go-sqlite3のドライバ設定
1. ソースコード内で`github.com/mattn/go-sqlite3`をインポートする。
2. データベース接続用の初期設定コードを記述する。
3. ドライバの初期化処理が正常に動作するか確認する。
### 2.2.3 DB接続の初期化
1. SQLite3への接続関数を実装する。
2. 接続エラー時の処理（ログ出力やエラー返却）を追加する。
3. 接続テストを実施し、接続成功を確認する。
### 2.2.4 クエリ実行の基本実装
1. CRUD操作の基本関数を実装する。
2. SQLクエリにプレースホルダを使用してセキュリティを確保する。
3. クエリ実行後の結果取得とエラーチェックを実装する。
## 2.3 godotenvによる環境変数管理の実装
### 2.3.1 .envファイルの作成
1. プロジェクトルートに.envファイルを作成する。
2. 必要な環境変数（DBパス、ポート番号、秘密鍵など）を記述する。
3. ファイルのパーミッションを確認し、開発者間で共有できる状態にする。
### 2.3.2 godotenvの読み込み設定
1. アプリケーション起動時に`godotenv.Load()`を呼び出す。
2. .envファイルから環境変数が正しく読み込まれるか確認する。
3. 読み込み失敗時のエラーログを出力する処理を追加する。
### 2.3.3 環境変数の取得
1. `os.Getenv`を用いて必要な変数を取得する。
2. 取得した値の妥当性をチェックする。
3. 必要に応じてデフォルト値を設定するロジックを実装する。
### 2.3.4 エラー処理の実装
1. 環境変数未設定時のエラーハンドリングを実装する。
2. エラー発生時に詳細なログを出力する。
3. 重大なエラー時にはアプリケーションの起動を中断する。
## 2.4 SNS基本機能のコーディング（ユーザー管理、投稿管理等）
### 2.4.1 ユーザー登録機能の実装
1. ユーザーモデル（構造体）を定義する。
2. ユーザー登録用のAPIエンドポイントを実装する。
3. 入力値のバリデーション処理を追加する。
### 2.4.2 ユーザーログイン機能の実装
1. ログイン用APIエンドポイントを定義する。
2. パスワード認証ロジックを実装する。
3. 認証成功時にトークン（セッションやJWT）の発行処理を組み込む。
### 2.4.3 投稿作成機能の実装
1. 投稿モデル（構造体）を定義する。
2. 投稿作成APIエンドポイントを実装する。
3. 入力チェックとエラーハンドリング処理を追加する。
### 2.4.4 投稿フィードの実装
1. 投稿一覧取得用のSQLクエリを作成する。
2. フィード表示用のAPIエンドポイントを実装する。
3. ページネーション機能を追加し、データ量に応じた取得を行う。
---
# 3. 単体テストの実施
## 3.1 ユーザー機能の単体テスト
### 3.1.1 ユーザー登録テストケース作成
1. 正常系の入力パターンを定義し、テストケースを作成する。
2. モックデータを用意してAPI呼び出しのシミュレーションを行う。
3. レスポンス内容とDB登録結果を検証する。
### 3.1.2 ユーザーログインテストケース作成
1. 有効な認証情報でログインテストケースを作成する。
2. 無効な情報でエラーが返るか確認する。
3. レスポンスコードとエラーメッセージを検証する。
### 3.1.3 パスワードハッシュテスト
1. パスワードハッシュ生成関数に対するテストケースを作成する。
2. 同一パスワードで常に同じハッシュが生成されるか確認する。
3. 異なるパスワード間でハッシュ値が異なることを検証する。
### 3.1.4 異常系テストの実装
1. 無効な入力値や欠損データでテストケースを作成する。
2. 例外処理が正しく動作するか確認する。
3. エラーメッセージの内容を詳細に検証する。
## 3.2 投稿機能の単体テスト
### 3.2.1 投稿作成テストケース作成
1. 正常な投稿データを用意し、テストケースを作成する。
2. 投稿作成APIを呼び出して結果を取得する。
3. DBに正しくデータが保存されたか検証する。
### 3.2.2 投稿編集テストケース作成
1. 既存の投稿データをモックとして準備する。
2. 編集用APIエンドポイントに対してテストを実施する。
3. 編集後のデータが正しく更新されているか確認する。
### 3.2.3 投稿削除テストケース作成
1. 削除対象となる投稿を選定し、テストケースを作成する。
2. 削除APIを呼び出してレスポンスを取得する。
3. DBから対象投稿が削除されているか確認する。
### 3.2.4 フィード取得テストケース作成
1. フィード表示用のモック投稿データを準備する。
2. フィード取得APIを呼び出し、レスポンスを取得する。
3. 取得したデータの整合性と件数を検証する。
## 3.3 Echoハンドラの単体テスト
### 3.3.1 ハンドラ関数のモック作成
1. Echoコンテキストのモックを作成する。
2. ハンドラ関数呼び出し用のテストコードを記述する。
3. モックを用いて出力結果が期待通りか確認する。
### 3.3.2 リクエスト・レスポンスの検証
1. テスト用のリクエストオブジェクトを生成する。
2. ハンドラ実行後のレスポンスオブジェクトを取得する。
3. ステータスコードおよびレスポンスボディを検証する。
### 3.3.3 ミドルウェアテストの実装
1. 各ミドルウェアの動作をシミュレートするテストケースを作成する。
2. リクエストチェーンの途中での処理結果を検証する。
3. エラー発生時のミドルウェア動作を確認する。
### 3.3.4 エラーハンドリングテスト
1. 異常な入力データを用いたテストケースを作成する。
2. エラーレスポンスの形式と内容を検証する。
3. ログ出力が正しく行われているか確認する。
## 3.4 データベース接続の単体テスト
### 3.4.1 DB接続テストの作成
1. テスト用のDB接続設定を定義する。
2. 接続関数を実行し、エラーが発生しないか確認する。
3. 接続成功後に簡単なクエリを実行して結果を検証する。
### 3.4.2 クエリ実行テストの実装
1. サンプルSQLクエリを準備する。
2. クエリ実行用関数を呼び出して結果を取得する。
3. 結果セットの内容と件数を検証する。
### 3.4.3 トランザクションテストの実装
1. トランザクション開始処理のテストケースを作成する。
2. 複数のクエリを実行し、コミット前の状態を確認する。
3. ロールバックとコミットの動作が正しいか検証する。
### 3.4.4 エラーハンドリングテスト
1. 意図的にエラーとなるクエリを実行するテストケースを作成する。
2. エラーハンドリング処理が実行されるか確認する。
3. エラーログの出力内容を検証する。
---
# 4. 統合テストとデバッグ
## 4.1 APIエンドポイントの統合テスト
### 4.1.1 テストサーバーの立ち上げ
1. 統合テスト用にテストサーバーインスタンスを起動する。
2. 使用ポートやエンドポイントの設定を確認する。
3. サーバー起動時のログを検証して問題がないことを確認する。
### 4.1.2 各エンドポイントのテストスクリプト作成
1. 各APIエンドポイントに対応するテストスクリプトを作成する。
2. テストリクエストのパラメータを設定する。
3. 実行結果をログに記録し、正常動作を確認する。
### 4.1.3 レスポンス検証の実装
1. 期待されるレスポンス内容を定義する。
2. テスト実行後のレスポンスと期待値を比較する。
3. 結果を詳細なログとして出力する。
### 4.1.4 テスト結果のログ収集
1. 各統合テスト実行結果を一元管理する仕組みを構築する。
2. ログファイルにテスト結果を出力する。
3. テストレポートを自動生成するスクリプトを実装する。
## 4.2 シナリオテストの実施
### 4.2.1 ユーザーシナリオの作成
1. ユーザー登録からログインまでの操作シナリオを作成する。
2. シナリオ内で実行すべき各APIの呼び出し手順を定義する。
3. シナリオの期待結果を明確に記述する。
### 4.2.2 投稿シナリオの作成
1. 投稿作成、編集、削除の一連のシナリオを作成する。
2. 各操作の入力データと期待結果を定義する。
3. テストスクリプトでシナリオ実行手順を自動化する。
### 4.2.3 フローシナリオの作成
1. ユーザーの一連の操作フロー（例：登録→ログイン→投稿→フィード取得）を設計する。
2. 各フローのステップごとにテスト項目を洗い出す。
3. シナリオ実行順序を明確にドキュメント化する。
### 4.2.4 シナリオ実行と結果検証
1. 作成したシナリオテストを順次実行する。
2. 各ステップの結果をログに記録し、期待値と比較する。
3. 異常が検出された場合は詳細なバグレポートを作成する。
## 4.3 パフォーマンステストの実施
### 4.3.1 ロードテストの設定
1. ロードテストツール（例：Apache Bench、wrk）を選定する。
2. 同時接続数やリクエスト数のシナリオを設定する。
3. テスト環境の構成と負荷条件を明確にする。
### 4.3.2 ストレステストの実装
1. 高負荷状態をシミュレートするテストケースを作成する。
2. テストスクリプトで急激なリクエスト増加を再現する。
3. サーバーのエラー応答やタイムアウトを監視する。
### 4.3.3 レスポンスタイム測定
1. 各APIエンドポイントの応答時間を測定するツールを設定する。
2. テスト実行中にレスポンスタイムを記録する。
3. 測定結果をグラフやレポートにまとめる。
### 4.3.4 ボトルネック分析
1. パフォーマンステスト結果から遅延箇所を特定する。
2. 該当するコードおよびDBクエリをレビューする。
3. 改善策を実装し、再テストで効果を検証する。
## 4.4 バグ修正とコードのリファクタリング
### 4.4.1 バグ報告の分析
1. テスト結果やログからバグ報告を収集する。
2. 再現手順を明確にし、原因箇所を特定する。
3. 修正優先度を決定する。
### 4.4.2 修正案の実装
1. 問題となっているコード箇所を修正する。
2. 修正内容をローカルブランチで実装する。
3. 変更内容をコミットし、レビューを依頼する。
### 4.4.3 再テストの実施
1. 修正後に該当する単体テストおよび統合テストを再実行する。
2. 修正が正しく反映されたか検証する。
3. 他の機能への影響が無いかチェックする。
### 4.4.4 コードクリーンアップの実施
1. 不要なコードやコメントを削除する。
2. リファクタリングツールを用いてコードの整理を行う。
3. コードの可読性および保守性を向上させる。
2. チャートをClineに入力する
先ほどのchart.mdを参照することで、このようにClineに渡すプロンプトがものすごく短くなりました。
@/chart.md の1.の作業を実行してください。
@/chart.mdはClineのプロンプトで使用できる機能です。
また、私は前回紹介したようにProject IDX上でClineとGemini 2.0 Flashを使用しているため、以下のプロンプトを追加して環境にあわせた作業をカスタマイズできます。
1.1は実行済みのためスキップしてください。
1.4は不要なのでスキップしてください。
もちろんchart.mdに記載されていない内容もプロンプトに追加できます。
ターミナルのコマンドはエスケープしないでください。
ターミナルでエラーが発生したときは原因を考えてください。
よく分かっていませんが、ここらへんの内容は.clinerulesに書いたほうが良いかもしれません。
前回紹介したProject IDX + Cline + Gemini 2.0 Flashの使用方法についてはこちら。
3. チャートは残す
プロンプトエンジニアリングでありがちなのが、何のプロンプトを入力したか覚えていないことですが、原因は入力したプロンプトを残していないところにあるので、たとえ不要になってもchart.mdは残しておいたほうが良いでしょう。
私の場合はchart.mdに「1. 推論モデルでチャートを作成する」と「2. チャートをClineに入力する」で紹介した各プロンプトも追記して残しておくようにしています。
使うときに追記した場所を削除して元通りにしておけばいいので、忘れないようにチャートにちゃーんと書いておきましょう。
また、私はRaspberry Pi Zero WHでCaddyのWebDAVファイルサーバーを動かしているため、chart.mdをUnixtimeでリネームした後、ここにアップロードしてスマホでも手順書として読めるようにしています。
Markdown形式なので、人間にとっても読みやすいのはありがたいですね。
おわりに
ところで今回プロンプトエンジニアリングを行っていくうえで基本情報技術者試験や応用情報技術者試験で学んだことがものすごく役に立ちました（chart.mdのデータ構造や、プロジェクトマネジメントのツールと技法など）
いよいよAIを操作するだけでも高度な情報技術が必要になるのかもしれませんね。
Discussion