Void Editor × Ollamaで開発を加速する実務ワークフロー

2025年8月28日

こんばんは！IT業界で働くアライグマです！
この記事では、私が日々使っている「Void Editor × Ollama」での開発ワークフローを、設計・実装・レビュー・テスト・ドキュメントまで通しで解説します。生成AIで“量産”するのではなく、安全に速く変更を届けるための実務ノウハウに寄せています。

全体像：Void Editor × Ollamaが開発にもたらす変化

一言でいえば「設計と生成の分離」「差分前提の出力」「検証の自動化」です。まずは変化点を3つに絞って把握します。

• 速度：仕様→実装→テスト→ドキュメントの各段をテンプレ化し、往復の手戻りを最小化。
• 品質：コーディング規約・差分出力・テスト優先をプロンプトで型化し、レビュー指摘の再発を抑制。
• 再現性：タスク単位のチェックリストと検収観点を固定し、誰が回しても同品質に近づけます。
• セキュリティ：シークレット/鍵/PIIを扱う出力は禁止。誤出力ガードをテンプレに組み込む。
• 可観測性：生成後の振る舞いは計測しなければ改善できません。ログ/メトリクス/トレースを前提に設計します。

補助的な背景は Cursor × ローカルLLMの実践テク と AIコーディング支援比較 にも触れています。環境選びの判断に役立つはずです。

環境準備：OllamaモデルとVoid Editorの初期設定

最初に迷うのはモデル選定とエディタ設定です。ここを型にすると実装速度とレビュー通過率が安定します。

• モデル選定：コード変換・リファクタ用（軽量・高速）と、設計/レビュー用（推論強め）を用意。
• コンテキスト設計：対象リポジトリの規約・フォルダ構成・コーディング規則を数行で常駐させる。
• Void Editor：テンプレ（関数仕様→実装、差分出力、テスト生成、ADR/RFC）をスニペット登録。
• シークレット管理：環境変数/Secret Managerのみ使用。プロンプトに秘匿情報を書かない。
• モデル切替：重い推論はバッチで、日常編集は軽量モデルで即時応答にする運用を分離。
• CI整合：ローカルのフォーマッタ/リンタ/テスト設定をCIと同一化し、出力揺れを無くす。

プロンプトの基礎を学ぶなら 大規模言語モデルを使いこなすためのプロンプトエンジニアリングの教科書 が分かりやすいです。誤用しがちな指定（過剰な禁止・冗長説明）は最小限にしましょう。

プロンプト設計：作業単位と出力形式を固定する

私の失敗は「丸投げプロンプト」で発生します。作業単位に分割し、出力を差分やコードブロックに固定するだけで、差し戻しが激減しました。例：

• 実装：関数仕様→関数/メソッド実装。前後の差分のみ提示、不要な解説文は出さない。
• リファクタ：目的（可読性/性能/安全性）と制約を明示。副作用回避・I/O不変更・動作等価を条件に。
• テスト：ケース表→`pytest`/`unittest`生成。失敗先に注目するネガティブケースを必ず含める。
• 移行：段階的リリース/互換層/データ移行手順を出力形式として固定。
• 観測性：ログ/メトリクス/トレースの挿入ポイントを指定し、出力に含める。
• 境界条件：入力制約/タイムアウト/リトライ/並行性の扱いをプロンプト側で明示する。
• アンチパターン：ファイル全書き換え/巨大関数/無根拠な最適化は禁止、を明言。

やってはいけない指定を先に固定すると、後工程のストレスが大幅に減ります。
テキスト整形の自動化は、繰り返し使うスクリプト化と相性が良いです。小さなユーティリティを書く場合は 作業が一瞬で片付く Python自動化仕事術 が役立ちます。

実装生成：関数粒度で分割し、差し戻しやすく

一気に大改修せず、関数/モジュール粒度で刻みます。小さな成功と小さな差し戻しを回す方が安全です。

• 粒度：I/F→実装→例外→境界値の順に小さく進める。巨大PRを避ける。
• 規約固定：フォーマッタ/リンタ（例：Black/ruff、Prettier、eslint）に合う形で生成させる。
• 根拠：仕様/チケット/ADRの引用行を明示。曖昧仕様はTODOで残し、別PRに分離。
• 計測：クリティカルパスはベンチマーク雛形を同時生成して回帰検知を容易にする。
• ドキュメント：docstring/READMEの差分も同梱し、実装と説明の乖離を防ぐ。
• 例外設計：エラー分類/再試行可否/メッセージ方針を統一し、呼び出し元契約を守る。
• フラグ運用：フィーチャーフラグで新旧挙動を切替、ロールバック容易性を確保。

レビューが揉めやすい箇所は、意図（設計判断）を1行コメントに残すと齟齬が減ります。

コードレビューと整形：規約・差分・テストの三点締め

生煮えの実装を“通るコード”にするのがレビューです。規約・差分・テストの三点を締めるだけで、指摘は大幅に減ります。

• 規約：リンタ/フォーマッタがゼロ警告で通ること。CIで再現できる。
• 差分：PRは“差分の理由”が読める粒度。関係ない整形は別PRに分ける。
• テスト：正常/異常/境界を網羅。再現手順のある不具合は先にFailing Testを置く。
• 可観測性：ログの粒度/構造化、メトリクス名、トレースのスパン設計を揃える。
• 性能予算：予算を超える変更は事前に根拠を提示。代替案とトレードオフを明記。
• レビュー観点：命名/SRP/副作用/境界値/例外/N+1/ロック順序/I/O回数を定点観測。
• 小さなPR：レビュー時間の上限を決め、越える場合はPRを分ける。

チームの癖は放置すると劣化します。定期的に過去PRを棚卸しし、再発指摘を規約へ昇華。変更の作法は 達人プログラマー ―熟達に向けたあなたの旅 の“良い変更”にも通じます。

仕様確認と内部リンク：検証→参照→差し戻し

“言い切るなら裏を取る”は開発でも同じです。内部リンクは仕様や設計資料への導線として機能させます。

• 検証：仕様・API契約・I/Fは一次情報で突き合わせ。破壊的変更はADR/RFCで根拠を残す。
• 内部リンク：関連記事や環境記事へのリンクを文脈で差し込む。例：Cursor × ローカルLLMの実践テク、AI支援比較。
• ショートコード：各章で多くても1つ。羅列せず文脈に沿わせ、同一ショートコードの重複は避ける。
• トレーサビリティ：チケット番号/コミット/ADRの相互リンクを徹底し、決定理由を追えるようにする。
• ソース優先：ブログやまとめは二次情報。一次情報（仕様書/実コード/公式ドキュメント）を基準にする。

リンクは“押して得をする”位置に置きます。導入とまとめでは入れません（読みのリズムを守るため）。

画像選定：低頻度代表URLからユニークに

写真は“読む速度”を整える道具です。語りが重たくなった章の末尾にだけ、意味のある1枚を置きます。

• 代表URL：`data/used_image_urls.md` の「重複削除」から選ぶ。
• ユニーク：同一記事内のベース名重複は禁止。横幅は `width="725″` を指定し、末尾に1枚のみ。
• 文脈一致：章の結論直前で挿入し、直前の段落に視覚補助の意図を1文添えます。

使い回しが続くとサイト全体の“見た目疲れ”が起こります。低頻度の候補をローテーションすると改善します。

検収チェックリスト：マージ前にここだけ確認

仕上げの一手間が品質を決めます。スニペット化してPR作成前に自動/手動で通します。

• 静的検査：リンタ/フォーマッタ/型チェックがゼロ。
• テスト：ローカル/CIで緑。カバレッジの急落なし。
• ドキュメント：README/ADR/コメントの更新漏れなし。
• リスク：破壊的変更は明記。ロールバック/フィーチャーフラグの用意。
• リンク：関連資料や参考記事への導線。導入/まとめには入れない。
• パフォーマンス：主要関数のベンチ結果/前回比を添付。劣化がある場合は緩和策を記す。
• 可観測性：ログ/メトリクス/トレースのイベント追加とダッシュボード更新を確認。
• 互換性：公開API/設定値/データスキーマの後方互換を点検。変更時は段階移行計画を添付。
• 依存関係：ライブラリ更新は変更理由/影響範囲/ロールバック手順を記載。

運用ルール群はエディタのスニペットにしておくと、チーム拡大にも耐えます。

運用のコツ：小さく出して安全に学ぶ

開発は“出してからが本番”です。仮説検証の回し方を型化すると、迷いなく次の改善に移れます。

• 短いスプリント：小PRで頻度高くマージ。リリースは段階的に。
• フェイルセーフ：フィーチャーフラグ/ロールバック手順/テレメトリをテンプレ化。
• ナレッジ化：成功したプロンプト/レビュー観点はスクラップ化し、次回の初速を上げる。
• 事後分析：失敗や逸脱は軽量なポストモーテムで学びに転換。再発防止のチェックに反映。
• ユーザ観測：実利用ログ/セッション記録から仮説を更新。開発の次の問いを明確化。

道具が変わっても、良いプロダクトは「誰のどの課題を解くか」を外しません。ツールはその精度と速度を底上げする位置づけです。

まとめ

今日紹介した流れは、明日から少しずつ差し込めます。実装・テスト・レビュー・ドキュメントのどこからでも導入可能です。

• 作業分割で差し戻しコストを下げ、出力形式（差分/コード/テスト）を固定する。
• 規約常駐（コーディング規約・レビュー観点）をプロンプトに常駐させてブレを抑える。
• 検収テンプレでマージ品質を安定させる。失敗はログに残し、次回のプロンプトへ。
• 観測と計測で改善サイクルを短縮。変更の効果を数値で捉える。
• 小さく速くを是にし、成功/失敗の学びを次のPRに即時反映する。