---

なぜ企業のAI開発は失敗し個人DIYは成功するのか

C言語の苦行とCOBOL・PowerBuilderの資産

昔、C 言語をかじって「プログラミングなんて二度とごめんだ」と感じた方の多くは、ロジックを考えるのが嫌いだったのではなく、ハードウェアのメモリ番地を人間が手作業で計算する「ポインタ」や、処理を軽くするための「シフト演算（(data >> 4) & 0x0F）」という機械都合のパズル にうんざりしたはずです。少し番地がズレただけで冷酷に Segmentation fault で強制終了する世界は、本来やりたい「便利な道具を作る作業」とは無関係な苦行でした。

一方で、かつて PowerBuilder や COBOL を使いこなしていた方は、実は現代の開発とまったく同じアーキテクチャをすでに体験しています。たとえば PowerBuilder は、普段は中間コード（P-Code）を仮想マシン（PBVM 等の DLL）で動かしつつ、実行ファイル（.exe）をネイティブ出力するときは 裏側で一度大量の C 言語ソースコードを自動生成（トランスパイル）し、外部の C コンパイラを呼び出して機械語へ変換する という仕組みを採っていました。「人間は人間に分かりやすい画面と業務ロジックだけに集中し、泥臭い C 言語や機械語への翻訳は裏のエンジンに丸投げする」という発想そのものです。

AIを隣の席の常駐プログラマにする役割分担

いま多くの企業が AI 導入で巨額の予算を溶かして失敗している最大の原因は、「何を作るか（仕様）」と「正しく動いているか（テスト）」まで AI に丸投げしてしまうこと にあります。AI は魔法の杖ではなく、「コーディング速度だけは人間の 1,000 倍速いが、指示されたことしか分からない新人プログラマ」だからです。

逆に、かつての開発現場で 「社内の隣の席に常駐プログラマ（外注 PG）に座ってもらい、自分が SE として仕様を渡して作らせ、その場で動かしてテスト・検収する」 スタイルを経験した人なら、AI エディタ（Antigravity IDE や VS Code ＋ Gemini 等）は最高の相棒になります。

開発の工程	従来の社内 SE × 常駐 PG 体制	現代のあなた（SE）× AI エディタ（PG）体制
要件・仕様決定	SE が画面項目、計算式、例外時の動きを決める	あなたが日本語で入力・処理・出力のルールを指定する
コード記述・ビルド	隣の席の常駐 PG が数日〜数週間かけて書く	AI が数秒〜数分で SwiftUI コードを書きビルドする
単体・結合テスト	SE が境界値やエラー系を触って検収する	あなたが実機で触り、おかしな挙動を見つけて突き返す
必要な言語知識	PG に指示が通じる設計力（細かな構文暗記は不要）	文法暗記は不要（気になる箇所だけ AI に解説させれば OK）

このように役割を切り分ければ、炊飯の水加減を計算する自分専用ミニアプリから、CPU 各コアの負荷モニター、全アプリのバージョン一括点検ツールまで、「欲しいソフトが世の中にないなら 10 分で作らせる」という究極の日曜大工（マイツール開発）が実現します。

---

Xcodeの壁を越えるSwiftPMと起動スクリプト

App Sandboxの壁とSwiftPMの威力

Mac 向けのネイティブアプリ（SwiftUI）を作るとき、最初にぶつかりやすい壁が 「Xcode プロジェクトの重さ」 と 「App Sandbox（アプリの隔離制限）」 です。

Xcode で通常の Mac アプリ用テンプレートを選ぶと、App Store 提出を前提とした厳格な App Sandbox が最初から有効になります。これは他人に配布するアプリとしては安全な仕組みですが、たとえば「自分の Mac の /Applications フォルダに入っている全アプリのバージョン一覧を読み取りたい」といったシステム管理ツールを作ると、サンドボックスに阻まれてフォルダの中身すら読めません。

全アプリの更新を一括判定する自作ツールの実例

実際に私が「フリーソフトを探しても納得いくものがないから」と AI に仕様を渡して作らせたお気に入りツールが、Mac 内の全アプリの更新有無をワンクリックで一覧表示する AppVersionChecker です。

仕様として AI に指示したのは、次のシンプルな入出力ルールだけでした。

1. /Applications 内の .app バンドルを走査し、内部の Contents/Info.plist から現在のバージョン（CFBundleShortVersionString）とアプリ名を取得する。
2. Mac App Store 経由で入れたアプリ（内部に _MASReceipt があるもの）は、Apple 公式の iTunes Search API（国コード JP）にバンドル ID を問い合わせて公開中の最新バージョンを取得する。
3. Web から直接ダウンロードしたアプリ で自動更新フレームワーク Sparkle を使っているもの（Info.plist に SUFeedURL があるもの）は、その配信 XML（Appcast）を読みに行って最新バージョンを取得する。
4. 現在値と最新値を比較し、新しいバージョンが出ている行にだけ 「更新ページを開く / App Store を開く」ボタン を表示する。
5. 毎回ターミナルを開くのは面倒なので、デスクトップの .command ファイル（カスタムアイコン付き）をダブルクリックするだけ でウインドウが立ち上がるようにする。

確認不可で更新ボタンが出た文字比較バグの教訓

このツールを最初に AI が書き上げて動かしたとき、「人間がテストを握ることの大切さ」が象徴的に現れる面白いバグが見つかりました。なんと、独自方式で外部から最新番号を取得できないアプリ（最新欄が 確認不可 と表示されている行）にまで、ズラッと「更新あり！」のボタンが出てしまったのです。

私が画面を見て 「最新が『確認不可』の行で更新ボタンが出ているよ」 と一言フィードバックしただけで、AI は即座に原因を特定し、「数値とドットで構成された有効なバージョン文字列のときだけ階層比較（compare(..., options: .numeric)）を行い、確認不可 や 確認中... のときは絶対に更新ボタンを出さない」よう数秒で修正してくれました。

まさにこれが、「人間はコードの暗記ではなく、動かして違和感を見抜く検収（テスト）に集中する」 という分担の醍醐味です。

---

SSDを削らないRAMDiskビルドと飛び地整理術

.buildをRAMDiskへ自動リンクする仕組み

SwiftPM でアプリを何度もビルド・改良していると、各プロジェクトの直下に .build という隠しフォルダが作られ、数百 MB 単位の中間ファイルが毎回書き込まれます。これを内蔵 SSD の上で繰り返すのは SSD 寿命（書き込み総量）の面でもったいないですし、かといってホームディレクトリ直下などあちこちに「飛び地」の作業フォルダが散らばるのも管理が気持ち悪いですよね。

そこで私は、「ソースコードはすべて ~/Desktop/swift/ フォルダの 1 箇所に集約し、各プロジェクトの .build（一時生成物）だけをシンボリックリンクで 16GB の RAMDisk（メモリ上の超高速仮想ディスク）へ逃がす」 という構成に統一しました。

#!/bin/zsh
# ~/Desktop/swift/link_ramdisk.sh
# デスクトップ配下の全Swiftプロジェクトの .build を RAMDisk へ自動退避するスクリプト
set -eu
setopt nullglob

SWIFT_ROOT="$HOME/Desktop/swift"
RAM_BUILD_ROOT="/Volumes/RAMDisk/$USER/swift-build"

# RAMDiskがマウントされていない場合は安全のため何もしない
if [ ! -d "/Volumes/RAMDisk/$USER" ]; then
  echo "RAMDisk が未マウントのためスキップしました。"
  exit 0
fi

mkdir -p "$RAM_BUILD_ROOT"

for proj in "$SWIFT_ROOT"/*(/); do
  if [ -f "$proj/Package.swift" ]; then
    proj_name="${proj:t}"
    target_dir="$RAM_BUILD_ROOT/$proj_name"
    mkdir -p "$target_dir"

    # 既存の .build がシンボリックリンクでなければ削除してリンクに置き換える
    if [ -e "$proj/.build" ] && [ ! -L "$proj/.build" ]; then
      rm -rf "$proj/.build"
    fi
    ln -sfn "$target_dir" "$proj/.build"
  fi
done

この link_ramdisk.sh を、Mac 起動時に RAMDisk を作成するスクリプト（~/bin/create_ramdisk.sh）の末尾から自動で呼び出すようにしておけば、Mac を再起動しても全自動で RAMDisk 上にビルド領域が再構築 されます。

容量不足code28の罠とAGENTS.md長期記憶

この RAMDisk ビルド運用で実際に 1 度だけ遭遇したトラブルと、二度と忘れないようにした工夫も共有しておきます。

1. ビルド中の ioError(code: 28) エラーの正体 : ある日突然 Swift のビルドが ioError(code: 28) で落ちたことがありました。Unix のエラーコード 28 は ENOSPC（ディスクの空き容量不足） です。原因を調べると、同じ 16GB RAMDisk 上に置いていた一時ダウンロード用フォルダ（Downloads_RAM）に約 14GB の巨大データを入れっぱなしにしており、Swift が必要とする数百 MB の作業領域が足りなくなっていました。不要ファイルを空けた瞬間に一発で復旧しました。
2. AGENTS.md で AI 自身に環境ルールを長期記憶させる : 新しい Swift ツールを AI に作ってもらうたび、人間が毎回「link_ramdisk.sh も実行してね」と指示するのは面倒です。そこで ~/Desktop/swift/AGENTS.md というルールファイルを 1 枚置き、「このフォルダに新規 Swift プロジェクトを作成した際は、必ず AI 自身が link_ramdisk.sh を実行して .build を RAMDisk へ向けること」 と明記しました。これでチャットが変わっても、AI が裏で勝手に SSD 保護設定まで済ませてくれます。

---

まとめ：欲しい道具は探すより10分で作る時代へ

かつて C 言語のポインタや複雑な開発環境の構築で遠ざかっていたとしても、今の時代は 「どういう道具が欲しいか」を明確に言葉にでき、動かしてテストできる人 が一番楽しくプログラムを作れる時代になりました。

1. 文法の丸暗記は手放し、自分は「仕様決定（SE）」と「テスト検収」に専念して AI を常駐プログラマとして使う
2. 自分専用の Mac ツールなら、App Sandbox に縛られない Package.swift（SwiftPM）＋ .command 起動で軽快に動かす
3. ソースは 1 つのフォルダにまとめ、.build は RAMDisk へ自動リンクして内蔵 SSD の摩耗をゼロにする

日常の中で「こんな小さな計算機やチェッカーがあったら便利なのに」と思ったら、ぜひ市販アプリを探し回る前に、AI エディタのチャット欄へあなたの仕様書を投げてみてくださいね！