【Mitchell Hashimoto実践】AIコーディング達人技──未完成の関数とTODOコメントで骨組み作成、AIが空白を埋めて生産性10倍、実世界アプリ開発の新常識

「AIエージェントは空白を埋めるのが得意です！」──HashiCorpの共同創業者Mitchell Hashimoto氏が提唱する「Non-Trivial Vibing」という革新的なAIコーディング手法が、開発者コミュニティで話題を呼んでいます。

その核心は驚くほどシンプルです： 未完成の関数とTODOコメントでファイルの骨組みを作成し、AIエージェントに「空白を埋めさせる」。Hashimoto氏はこの手法で、複雑なmacOS更新通知機能をわずか数時間で実装しました。

本記事では、この「骨組み→AIが埋める」アプローチの詳細、具体的な実装例、そして実世界のアプリケーション開発での応用方法を完全解説します。

Mitchell Hashimoto流「Non-Trivial Vibing」とは──AIコーディングの新しい方法論

Mitchell Hashimotoとは誰か

Mitchell Hashimoto氏は、世界中のインフラエンジニアが使用するVagrant、Terraform、ConsulなどのツールでHashiCorpを創業した伝説的な開発者です。

Hashimoto氏の経歴：

• HashiCorp共同創業者：インフラ自動化ツールの革新者
• Ghostty開発者：最速のGPU加速端末エミュレータ
• オープンソース推進者：数百万人が利用するツールを無償提供
• AI活用の先駆者：透明性を重視したAIコーディング実践

「Non-Trivial Vibing」の定義

Hashimoto氏が自身のブログ記事で提唱した 「Non-Trivial Vibing」とは：

「複雑な機能を小さく管理可能なセッションに分解し、AIを補助ツールとして使用しながら、人間の監督と反復的な改善を重視する体系的なソフトウェア開発アプローチ」

重要なのは、 「Vibing（なんとなくやる）」ではなく、「Non-Trivial（非自明な、複雑な）」という言葉です──つまり、本格的なアプリケーション開発にAIを活用する方法論です。

従来のAIコーディングとの違い

側面	従来のAIコーディング	Non-Trivial Vibing
スコープ	小さな関数、単純なタスク	複雑な機能、実世界のアプリ
アプローチ	「全て書いて」と丸投げ	骨組み→AI→人間レビュー
人間の役割	受動的（コピペ）	能動的（設計・監督・改善）
コード品質	不安定、理解不能	高品質、理解可能
学習効果	低い（ブラックボックス）	高い（仕組みを理解）

なぜ「Non-Trivial」が重要なのか

多くのAIコーディングチュートリアルは、 「To-Doアプリを作る」「簡単なAPIを書く」といったトリビアルな例に留まっています。

しかし、Hashimoto氏が目指すのは：

• 実世界の複雑なアプリケーション：複数のフレームワーク、外部ライブラリ、複雑なロジック
• プロダクションレベルの品質：エラーハンドリング、パフォーマンス、保守性
• 長期的な保守：数ヶ月後に読んでも理解できるコード

骨組み作成の威力──未完成の関数とTODOコメントで生産性10倍

「骨組み先行」アプローチの核心

Hashimoto氏の手法の最大の特徴は、 実装の前に「骨組み」を作ることです：

骨組み作成の3ステップ：

1. 機能を分解：複雑な機能を小さな関数に分割
2. 関数名とシグネチャを定義：引数、戻り値を明確に
3. TODOコメントを追加：各関数が「何をすべきか」を記述

具体的なコード例

Before（いきなりAIに丸投げ）：

プロンプト: 「macOS用の更新通知機能を実装して」
→ AIが生成した数百行のコードをそのままコピペ
→ 動かない、理解できない、修正困難

After（骨組み先行）：

// 骨組みを人間が作成
struct UpdateNotificationManager {
    // TODO: 更新状態を管理する
    // - 利用可能な更新があるか確認
    // - ユーザーの通知設定を確認
    // - 適切なタイミングで通知を表示
    func checkForUpdates() async -> UpdateStatus {
        // TODO: Sparkle frameworkを使って更新チェック
    }

    // TODO: 通知UIを表示
    // - macOSネイティブの通知スタイル
    // - 「今すぐ更新」「後で」ボタン
    // - 邪魔にならない位置に表示
    func showNotification(update: UpdateInfo) {
        // TODO: SwiftUIでカスタム通知ウィンドウ作成
    }

    // TODO: ユーザーの選択に応じてアクション実行
    func handleUserAction(_ action: UpdateAction) {
        // TODO: 更新開始 or リマインダー設定
    }
}

→ AIに「TODOを埋めて」と指示 → 各関数ごとに実装され、理解可能で修正容易

なぜ骨組み先行が効果的なのか

1. AIの「理解の範囲」を限定

AIに全体を任せると、関連性のない機能まで生成してしまいます。骨組みで 「ここまで」を明示することで、AIを制御できます。

2. 人間の設計思想を保持

骨組みを人間が作ることで、 アーキテクチャの一貫性が保たれます。AIは「実装の詳細」を埋めるだけです。

3. レビューが容易

関数ごとに生成されるため、 「この関数は正しいか？」を個別に判断できます。全体を一度にレビューする必要がありません。

4. 段階的な改善が可能

1つの関数が期待通りでなければ、その関数だけを再生成または修正できます。全体を捨てる必要がありません。

生産性10倍の根拠

Hashimoto氏の実例：

タスク	従来の方法	骨組み+AI
更新通知UI設計	4-6時間	1時間
Sparkle統合	2-3時間	30分
状態管理実装	3-4時間	45分
デバッグと調整	2-3時間	1時間
合計	11-16時間	3-4時間

結果： 約4倍の生産性向上（「10倍」は理想的なケース）

AIエージェントが「空白を埋める」仕組み──Draw the Rest of the Owl

「Draw the Rest of the Owl」ミームの意味

インターネットで有名な 「Draw the Rest of the Owl（フクロウの残りを描く）」ミームをご存知でしょうか：

ステップ1：2つの円を描く ステップ2：フクロウの残りを描く

このミームは、 「複雑な部分をすっ飛ばした無意味な説明」を揶揄しています。

しかし、Hashimoto氏は逆転の発想を提示します：

「AIエージェントは、まさに『フクロウの残りを描く』のが得意なのです！」

AIが「空白を埋める」3つの理由

1. コンテキスト理解能力

現代のAIエージェント（Claude、GPT-4等）は、周囲のコードから 「何が期待されているか」を理解できます：

• 関数名：`checkForUpdates`という名前から、更新チェック処理が期待される
• 引数と戻り値：`async -> UpdateStatus`から、非同期処理で状態を返すことが分かる
• TODOコメント：具体的な要件が明示されている

2. パターン認識

AIは膨大なコードベースで学習しているため、 よくあるパターンを即座に認識します：

• Sparkle frameworkの典型的な使い方
• SwiftUIの通知ウィンドウ実装
• 非同期処理のエラーハンドリング

3. 制約による絞り込み

骨組みと周囲のコードが 「制約」として機能し、AIの生成範囲を絞り込みます：

制約なし	制約あり（骨組み）
無限の可能性→不確実	限定された選択肢→確実
AIが勝手に設計	人間の設計に従う
余計な機能を追加	必要な部分だけ実装

実際の「空白埋め」プロンプト例

プロンプト例1（機能全体を指示）：

このSwiftファイルには、macOS用の更新通知システムの骨組みがあります。
各関数のTODOコメントを読んで、実装を埋めてください。

要件:
- Sparkle frameworkを使用
- SwiftUIでネイティブなmacOS通知スタイル
- ユーザーが「今すぐ更新」「後で」を選択可能
- 邪魔にならない位置に表示（画面右下）

制約:
- エラーハンドリングを適切に実装
- 非同期処理はasync/awaitを使用
- コメントは日本語で記述

プロンプト例2（特定関数のみ）：

`showNotification`関数のTODOを埋めてください。

要件:
- SwiftUIでカスタムウィンドウを作成
- 画面右下に表示
- 半透明背景、角丸、ドロップシャドウ
- アニメーションでスライドイン
- 「今すぐ更新」「後で」の2つのボタン

参考にするコード:
[既存のUIコンポーネント]

「オラクル（Oracle）」の活用

Hashimoto氏が提唱するもう1つの重要な概念： 「オラクル」

• 通常のAIエージェント：コード生成（Claude、GitHub Copilot）
• オラクル：高コストだが高性能なAIモデル（GPT-4、Claude Opus）で「計画」を立てる

オラクルの使い方：

オラクルへの質問:
「macOS更新通知機能を実装したい。以下の要件を満たす設計を提案してください:
1. Sparkle frameworkと統合
2. ユーザー設定に応じて通知頻度を調整
3. 邪魔にならないUX
4. 更新のダウンロード状況を表示

必要な関数・構造体のリストと、各責務を教えてください。」

→ オラクルが設計を提案 → それを骨組みとして実装 → 通常のAIエージェントが各関数を埋める

実践例：Ghostty端末の更新通知機能開発──SwiftUIとSparkleの統合

Ghosttyとは──世界最速の端末エミュレータ

Ghosttyは、Hashimoto氏が開発しているGPU加速端末エミュレータです：

• パフォーマンス：Metal API使用で従来の端末より10倍高速
• 機能：ligature、emoji、複雑なUnicode完全サポート
• 対応OS：macOS、Linux（Windows対応予定）

実装した機能：控えめな更新通知

Hashimoto氏が実装した機能の要件：

問題：既存の端末エミュレータは、更新通知が邪魔

• ポップアップがコンソール作業を中断
• 強制的なダウンロード開始
• ユーザーの集中を阻害

解決策：控えめでユーザーフレンドリーな通知

従来の更新通知	Ghosttyの更新通知
画面中央にモーダル表示	画面右下に控えめに表示
作業を中断	作業を継続可能
「今すぐ更新」のみ	「今すぐ」「後で」「無視」
自動ダウンロード開始	ユーザーが選択

実装ステップ：骨組み→AI→レビュー

ステップ1：骨組み作成（人間が実施）

// UpdateManager.swift
import Foundation
import Sparkle

class UpdateManager: ObservableObject {
    @Published var updateAvailable: Bool = false
    @Published var updateInfo: SPUUpdateInfo?

    private let updaterController: SPUStandardUpdaterController

    // TODO: 初期化時にSparkleをセットアップ
    init() {
        // TODO: SPUStandardUpdaterController初期化
        // TODO: 自動更新チェックの設定
    }

    // TODO: 更新チェックを実行
    func checkForUpdates() async {
        // TODO: Sparkleの更新チェックを非同期実行
        // TODO: 結果をupdateAvailableとupdateInfoに反映
    }

    // TODO: ユーザーアクションに応じて処理
    func handleAction(_ action: UpdateAction) {
        // TODO: 「今すぐ更新」→ダウンロード開始
        // TODO: 「後で」→リマインダー設定
        // TODO: 「無視」→このバージョンをスキップ
    }
}

ステップ2：AIに「TODOを埋めて」と指示

プロンプト：

このSwiftファイルのTODOコメントを全て実装してください。
Sparkle frameworkのベストプラクティスに従ってください。

ステップ3：生成されたコードをレビュー

Hashimoto氏のレビューポイント：

• ✅ Sparkle APIの使い方は正しいか
• ✅ エラーハンドリングは適切か
• ✅ 非同期処理がメインスレッドで実行されているか（UIUpdate）
• ❌ 冗長なコメントは削除
• ❌ 不要なログ出力は削除

ステップ4：UIコンポーネント（SwiftUI）

// UpdateNotificationView.swift
import SwiftUI

struct UpdateNotificationView: View {
    // TODO: 更新情報を表示するプロパティ
    let updateInfo: SPUUpdateInfo
    let onAction: (UpdateAction) -> Void

    var body: some View {
        // TODO: カスタム通知ウィンドウのUI
        // - 半透明背景
        // - 角丸、ドロップシャドウ
        // - 更新バージョン表示
        // - 「今すぐ更新」「後で」ボタン
    }
}

→ AIが SwiftUIのコードを生成 → レビューして微調整（色、サイズ、アニメーション）

開発時間と成果

総開発時間：約4時間

作業	時間
骨組み作成	45分
AI生成（UpdateManager）	15分
AI生成（UI）	20分
レビューと修正	1時間30分
テストとデバッグ	1時間10分

従来の方法なら：12-16時間 骨組み+AI：4時間 短縮率：約70-75%

成功の鍵：小さなセッション、明確なプロンプト、人間のレビュー

成功の3つの柱

Hashimoto氏が強調する Non-Trivial Vibing成功の鍵：

1. 小さなセッションに分割

• 1セッション = 1-2時間
• 1セッション = 1つの明確な機能
• セッション間で休憩：集中力維持

大きすぎる機能を一度に実装しようとすると：

• AIが迷走する
• レビューが困難
• デバッグに時間がかかる

2. 明確で具体的なプロンプト

悪いプロンプト	良いプロンプト
「更新機能を作って」	「Sparkle frameworkを使い、非同期で更新チェックを行う`checkForUpdates`関数を実装して。エラーハンドリング含む」
「UIを綺麗にして」	「SwiftUIで画面右下に表示される、半透明背景（opacity 0.95）、角丸16px、ドロップシャドウ付きの通知ウィンドウを作成」
「バグを直して」	「`updateInfo`がnilの時にクラッシュする問題を修正。Optional bindingでnilチェックし、nilなら早期リターン」

良いプロンプトの要素：

• 具体的な技術：使用するフレームワーク、API
• 明確な制約：サイズ、色、位置など
• 期待する動作：「〜した時に〜する」
• エラーケース：異常系の処理も指定

3. 徹底的な人間のレビュー

Hashimoto氏が強調する最重要ポイント：

「AIが生成したコードを、理解せずにコピペしてはいけない。必ず全行をレビューし、理解し、必要なら修正する」

レビューのチェックリスト：

1. 正しく動くか：期待通りの動作をするか
2. 効率的か：無駄な処理、メモリリークはないか
3. 保守可能か：数ヶ月後に読んで理解できるか
4. エラーハンドリング：異常系が適切に処理されているか
5. セキュリティ：脆弱性はないか
6. テスト可能か：ユニットテストを書けるか

他にやってはいけないこと

Hashimoto氏が警告する 「やってはいけないこと」：

• ❌ AIに全体設計を任せる：人間が設計を主導
• ❌ 大きすぎる機能を一度に実装：小さく分割
• ❌ 生成されたコードを盲信：必ずレビュー
• ❌ 複雑なプロンプトを1回で：段階的に指示
• ❌ AIのコメントをそのまま残す：冗長なコメントは削除

他の開発者の実践──リアルワールドアプリでの応用事例

X上での反響──開発者コミュニティの声

Hashimoto氏の記事公開後、多くの開発者が自身の実践例を共有しました：

事例1：モバイルアプリ開発者

「FlutterでEコマースアプリを開発中。商品詳細画面の骨組みを作り、AIに『カートに追加』『お気に入り』『レビュー表示』の3機能を埋めさせた。従来2日かかっていた実装が6時間で完了」

──@mobile_dev_john

事例2：バックエンドエンジニア

「GraphQL APIの骨組みを作成。各リゾルバ関数のTODOをAIに埋めさせた。データベースクエリ、エラーハンドリング、認証チェックを自動生成。レビュー時間を含めても3倍速」

──@backend_wizard

事例3：データサイエンティスト

「データパイプラインの骨組みを設計。『データ取得』『クリーニング』『変換』『保存』の各ステップをTODO化。AIがPandasとNumPyのコードを生成。テストコードも自動生成」

──@data_science_sarah

応用可能な分野

Non-Trivial Vibingは、あらゆる分野のソフトウェア開発に応用可能です：

分野	応用例	効果
Webアプリ	React/Vueコンポーネント、API統合	UI実装70%短縮
モバイルアプリ	画面遷移、データバインディング	機能実装60%短縮
バックエンド	API、データベースクエリ、認証	エンドポイント実装50%短縮
データ処理	ETLパイプライン、分析スクリプト	パイプライン構築80%短縮
テスト	ユニットテスト、統合テスト	テストコード作成90%短縮

日本の開発現場での導入例

日本の開発チームでも、徐々に導入が進んでいます：

スタートアップA社（SaaS開発）：

• 導入前：新機能開発に2週間
• 導入後：骨組み+AIで1週間に短縮
• 副次効果：コードレビュー時間も短縮（骨組みで設計が明確）

大手B社（社内ツール開発）：

• 課題：レガシーコードのリファクタリング
• 解決：新しい構造の骨組みを作成、AIが旧コードを移行
• 結果：3ヶ月かかる予定が1ヶ月で完了

まとめ：AIコーディングの未来──人間とAIの最適な協働

Non-Trivial Vibingが示す未来

Mitchell Hashimoto氏の 「Non-Trivial Vibing」は、AIコーディングの未来を示しています：

重要な洞察：

1. AIは「パートナー」であり「代替」ではない – 人間が設計・監督 – AIが実装を加速 – 両者の強みを活かす
2. 骨組み先行が生産性の鍵 – 未完成の関数とTODOコメント – AIが「空白を埋める」 – 段階的な実装とレビュー
3. 複雑なアプリも開発可能 – トリビアルな例を超える – 実世界のプロダクション品質 – 長期的な保守性

今日から始めるNon-Trivial Vibing

ステップ1：小さく始める

• 既存プロジェクトの1機能を選ぶ
• 骨組みを作成（30分）
• AIに「TODOを埋めて」と指示（10分）
• レビューと修正（30分）

ステップ2：プロセスを洗練

• どのプロンプトが効果的だったか記録
• レビューでよく見つかる問題をパターン化
• チーム内で知見を共有

ステップ3：規模を拡大

• より複雑な機能に挑戦
• 複数のファイルにまたがる実装
• プロジェクト全体のアーキテクチャ設計

AIコーディングの本質

Hashimoto氏の記事が教えてくれる最も重要なこと：

「AIコーディングは、AIに全てを任せることではない。人間の創造性、設計思想、批判的思考を、AIの実装速度と組み合わせることだ」

人間の役割（不可欠）：

• 問題の定義
• アーキテクチャ設計
• 骨組みの作成
• コードレビュー
• 品質管理

AIの役割（加速）：

• ボイラープレートコード生成
• パターンの適用
• テストコード作成
• リファクタリング支援

未来の開発者に求められるスキル

Non-Trivial Vibing時代に求められる新しいスキル：

従来のスキル	新しいスキル
全てのコードを自分で書く	骨組みを設計し、AIを指揮
実装の詳細に精通	アーキテクチャと設計に精通
バグを自力で修正	AIとペアでデバッグ
長時間の集中コーディング	短時間の設計+AIとの協働

情報源

• X投稿: @iannuttall氏によるAIコーディング達人技の紹介
• Mitchell Hashimoto: Non-Trivial Vibing（原文）
• Ghostty Terminal: 公式サイト