まずは、動画をご覧ください。

生成AIブームがここ数年急激に発展してきているわけですが、生成AIを個人が利用する場合は、ネットワークを通じてクラウドを使うしかないだろうと最初は見ていましたが、

最近はそれをMac mini上のローカルLLMで行おうとする人も増えています。これは、かつて流行した「自宅Webサーバー」を思い起こさせます。しかし「自宅Webサーバー」ブームは短命でした。というのは、機器のメンテナンスやウイルス感染、災害リスクが重くのしかかって個人が自宅で抱えていくのにはちょっと無理な発想だったわけです。

ローカルとクラウドの長所短所を考え合わせれば、やはりハイブリッド化していくのが合理的に思えてきますね。

私の場合ですが、今のところはクラウドだけを使っています。どの大手のAIにも移行できるように、ソースはtxtファイルをベースにして言語はPythonなどの一般的な言語を中心にしています。現在は成り行き上、Googleを使っています。Googleは何でも揃うのでラクと言うことでしょうか。Notebook・Gemini・Google AI Studioを連携させています。これらをうまく活用するための3つのポイントについて、大手IT企業のアプローチとの対比を交えながら解説します。

ポイント1：Gemini Notebookに「知識」を蓄える

AIを開発パートナーとして機能させるための第一歩は、例えばNotebookへ前提知識（コンテキスト）を溜め込むことだと思います。溜め込みを判断するのはあくまで私です。生成AIに勝手に任せることはしません。やっぱり自分が中身を知っていることは重要ですから。私が生成AIによるコーディングを実行できたのも、imakatブログへの投稿の蓄積、自前でネットから拾い上げながらコツコツ作ってきたプログラムコードの蓄積、その他もろもろ、それらを知識ソースとして投入できたことが非常に大きいです。
古臭いと感じるかもしれませんが、年月かけてブログ投稿を積み重ねるのが役に立つと思います。SNSは瞬間の出来事の切り取りと感じた印象だけを記録するので知見の蓄積としてはちょっと弱い、やっぱりブログがいいと思います。始めるのは若ければ若いほどいいと思います。身近な改善や経験を備忘録のつもりで書いていく、記事の投稿の目標は、ばらつきはあるとしても月１点以上がいいと思います。大事な事は職業上の秘密には絶対に触れないことです。私としてはこのWordPressのブログをコツコツと続けてきて本当によかったと感じています。

Notebookを用途に合わせて明確に区分し、知識資産を分類・配置します。

大手IT企業と個人ハンドメイドの対比

具体的な運用設計

• 目的別に「図書館」を分ける
  • 自分用imakat図書館：日々の開発・ブログ記事執筆、メンテナンス・デバッグを行うためのプライベートな知識ベース。
  • 公開用imakat図書館：外部共有、ブログ記事発信、公開向けのオープンな知恵袋。
• ソース（ファイル）の厳格な区分ルール
  • 実行用コード（exe.txt）：手元で実際に動作するコード。自分用図書館にのみ格納し、公開用には一切含めません。
  • 公開用コード（pub.txt）：後述のソフト秘匿化（サニタイズ）を施したコード。両方の図書館で共有します。
  • imakatブログ（公開）.txt：オープンな技術ノウハウや趣味雑学他の発信記事。両方の図書館に配置します。
  • 外部備忘録.txt（※重要）：
    • 内部備忘録【内】：個人情報や個人的な日記など、外部秘にしたい記録（AI・Notebookには一切連携しない）。今後、セキュリティに強いAppleのAIに含めることになると思います。
    • 外部備忘録【外】：作業記録、試行錯誤のチャットログ、技術アイデアなど。知識や経験の蓄積として自分用図書館にリンクさせ、AIの頭脳を育てます。

ポイント2：ハード秘匿化するモジュールを組み込む

クラウド型生成AIにコードを渡す際、最も恐ろしいのが認証情報や特定ファイルIDの漏洩です。これを防ぐため、「二層秘匿化」を行いました。ただし、この秘匿化の登録もAIに任せるのではなく私が判断します。

大手IT企業と個人ハンドメイドの対比

具体的な運用設計

• 第1層：ハード秘匿化（実質的セキュリティ）
  スプレッドシートIDやAPIキーをコード内に直接ベタ書き（SPREADSHEET_F8_ID = “1_ABCDabcd…”）せず、ローカルの .env ファイルへ隔離します。コード側は、Pythonの場合、 os.getenv(“SPREADSHEET_F8_ID”) で環境変数から動的ロードする構成を標準化します。
• ハード秘匿化モジュールはNoteBookで一元管理
  生成AIのカスタム指示に「プログラムを作成している最中に、秘匿情報の設定が必要になったら、NoteBookへ行って秘匿情報にパラメータを設定してもらってパラメータだけを持ち帰って来ること。」と設定しておきます。AIに直接生データを触らせず、Notebookが安全なパラメータ名だけをコード側に橋渡しします。
• 第2層：ソフト秘匿化（見た目・見栄えの安全性）
  メールアドレスや氏名などの固有名詞は、認証突破に直結しなくてもコードに残ると不格好で不用心です。公開用コード（pub.txt）を出力する段階で、これらの文字列を安全にマスキングします。

ポイント3：エラー修正プロセスを確実に実行する

実は、エラーへの対処が一番難しいところです。２つの問題があります。一つは、時間が経つと、記憶も薄れ、このエラーはどのプログラムが関係していたのか思い出せなくなることです。突然のエラーは焦りまくるので尚更です。もう一つは、NoteBookが画像動画の解析能力がほとんどないことです。従って、エラー時につきものの、エラーのスクショはGeminiに解析してもらうことが入り口になります。ここは将来はNoteBookにその解析能力がつくことを期待するものですが。そうした得手不得手のある中で、強みを活かした連携フローを敷いてみました。

大手IT企業と個人ハンドメイドの対比

具体的な運用設計

• 新規開発・改善のフロー
  • NoteBookに相談：まずは知識が蓄積されているNoteBookで過去資産や影響範囲を照合。
  • 規模に応じた切り分け：軽微な内容はNoteBook内で完結。400行を超える大規模ロジックや複雑な構造刷新は、広大なコンテキスト長を持つ Google AI Studio へ引き継いで一気に生成します。
  • 秘匿化連携：コード生成の途中でキーやIDが必要になったら、常に横の「NoteBook（ハード秘匿化モジュール）」へ依頼してパラメータを取得します。
• エラー修正のリレー
  • Geminiにエラー画像を投入（一次受付・言語化）：画面スクショをGeminiに渡すだけで、根本原因や関連キーワードを正確にテキスト化（短い修正ならそのままGeminiで修正完了）。
  • NoteBookに投げてファイル特定＆指示書作成（司令塔）：言語化されたキーワードをもとにNoteBookが全コード（exe.txt等）を横断検索し、「該当ファイルの特定」と「AI Studio用の修正指示書」を出力。
  • AI Studioで修正・完結（確実な実行）：指示書をAI Studioに流し込み、長文コードの整合性を保ったまま確実に修正を完了。

まとめ

さて、今回は、クラウド型生成AIについてその核心を３つのポイントにまとめたわけですが、こうやって記事を書いていても、まだなお、モヤモヤしているのは、3番目の、エラー処理のところです。Geminiに画像解析をさせてNotebookに引き継いでコードを抽出する、というところです。ここを一つにまとめたいのです。そこで、「画像解析からコード抽出」の部分を、ローカルLLMで処理することに挑戦してみたいと思います。その後で、コードが大規模の場合AI Studioへ引き継ぐのは、これはもう仕方ない事だと思います。だからハイブリッド型になりますね。

ただし挑戦するにしても、私にとって生成AIを含めたデジタル関係の趣味に掛けられるお金は月3000円くらいまでです。YouTubeを見ていると、３社以上の生成AIを契約して月10万円以上かけているような、おそらく本職がデジタル関係の方がたくさんいらっしゃるわけですが、私は生活費の一部から出費するわけですので、身の丈に合ったサービスを利用することになります。

改めて感じることですが、大企業から学ぶ真似ることは面白いと感じます。AIに聞けば、大企業がどのように諸課題を乗り越えているか解説してくれます。それを参考にして、それを小さくして簡単にして自分で作り込む。そのプロセスは結構未知な世界でワクワクするところです。そんなマインドが、個人開発を破綻させず、安全な長期利用につながっていくものと考えます。

動画をご覧ください。

コードと要約(クリック)

自作パペット_py.pub.txt 要約： このシステムは、顔認識と音声入力を利用してリアルタイムで動作するデスクトップパペットを実現します。 run_ui.pyは、パペットの各種設定を行うGUIアプリケーションです。キャラクターの新規作成、複製、選択、そしてボリューム閾値、グローバルスケール、顔の傾き制限、目の感度、カメラ/マイクIDといったパラメータ調整機能を提供します。これらの設定はキャラクターごとにJSONファイルとして保存されます。 run_puppet.pyは、UIで選択・設定されたキャラクターとパラメータに基づき、実際のパペット動作を制御するスクリプトです。OpenCVとMediaPipe Face Meshを用いてカメラ映像から顔の傾き、目の動き、口の形を検出し、マイクからの音声ボリュームと連携させてアバターの頭の回転、視線、口の動きをリアルタイムで再現します。キャリブレーションデータもキャラクターごとに保存されます。 Automatorスクリプトは、これらのPythonスクリプトの実行を補助します。「自作パペット起動.app」は設定UIを立ち上げ、「パペット書き出し起動.app」はPixelmator Proで開いているドキュメントの各レイヤーをPNG画像として書き出し、キャラクターごとの設定JSONを自動生成した後、該当するパペットを起動する一連の処理を行います。これにより、Pixelmator Proでの画像編集からパペット起動までがスムーズに連携されます。

公開スクリプトに関するお問い合わせは以下へ↓

なぜパペットを自作しようと思ったのか？

最大の理由は**「コスト」**です。
Adobeの素晴らしいパペットを使うためには、当然ながらAdobeのサブスクリプションに加入する必要があります。一番安いプランの組み合わせでも、月額1,200円ほどかかってしまいます。
「このキャラクターを使うためだけに、毎月課金し続けるのはどうなんだろう？」と悩んでいました。今は生成AI（画像生成AIやテキスト生成AI）がこれだけ発達し、メディアの加工やプログラムの作成まで何でもできる時代です。「それなら、AIの力を借りて自分で作ってしまおう！」と思い立ったのがきっかけです。

新キャラクター「いまかっちゃん（仮）？」

というわけで、完全自前で作り上げたのがこちらのパペットです。（※名前は暫定で「いまかっちゃん」と思いつきましたが、ちょっと変な感じもしています。）
Adobeのパペットと比べてしまうと多少見劣りする部分はありますが、動画用としては十分な機能を持っています。
音声連動： 私が話す声に連動して口がパクパクと動きます。
目の動き： 上目遣いなど、視線も動きます。
首の動き： 多少ですが顔の向きも変わります。（※現状、少し不安定な動きになることがあり、今後の課題です）
動画を作る上での「使い物」にはなんとか仕上がったかなと、個人的には割り切って満足しています。

Google Geminiに丸投げ！？

「どうやって作ったの？」と疑問に思うかもしれませんが、実はプログラミングの大部分は**AI（Google Gemini）**にお願いしました。
Geminiに質問する： 日本語で「こういう動きをするプログラムを書いて」と質問し、Pythonのコードを書いてもらいます。Geminiは非常に賢く、どんどんコードを生成してくれました。
パーツ画像の用意： 目（上・下・右・左）、口（開・閉）、体、頭など、パーツごとに細かく分けた画像（PNG形式）を用意します。
フォルダ構成： Macの中に専用フォルダ（mypuppet_systemなど）を作り、Pythonの実行ファイル（run_puppet.py）と、先ほどの画像パーツ群（assetsフォルダ）を格納して連動させました。

Mac「Automator」で起動を劇的にラクにする方法

自作プログラムの弱点として、「毎回ターミナル（黒い画面）を開いてコマンドを打ち込まないと起動しない」という厄介な問題がありました。これでは面倒ですよね。
そこで、Mac標準アプリの**「Automator」**を使って、ワンクリックで起動できるように一工夫しました。
手順： Automatorを立ち上げ、「シェルスクリプトを実行」を選択。そこにターミナルで打ち込んでいた短いコマンドをコピペするだけ。
アプリ化： これをアプリケーションとして保存すれば、**「自作パペット起動.app」**の完成です！
これからは、このアプリアイコンをダブルクリックするだけで、サクッとパペットを呼び出せるようになりました。

OBSへのパペット設定

OBSへのパペットの組み込みですが、OBSのソース→ウインドウキャプチャ、この中から、パペットのあるウインドウを選択します。

STREAM DECKがあると便利です。マルチアクションにて、OBS.app→自作パペット起動.app、と設定すればラクです。

さてと。。

その後の改善として、Pixelmator Proとの連携を作っています。形になったら紹介します。
生成AIを活用すれば、プログラミングの深い知識がなくても、日常の「ちょっと不便」「コストを削りたい」を解決できるツールが作れてしまいますよね。便利な時代になりました。

はじめに

コード作成って何？なんとも刺さりの悪い言葉なのですが、昔からある言い方に直せば、「コンピュータプログラム」のことです。これが長ったらしいので、コードと呼んでいます。英単語ではcodeです。音楽で使う和音を意味するコードはchordですね。綴りが違います。能書はこのくらいにして中身に入ります。

コードと要約(クリック)

❶公開用スクリプト作成_pub.txt： 要約：この workflow は、選択した *_exe.txt ファイルから公開用 *_pub.txt を生成する自動処理である。保存先は M1 側ボリュームに固定し、Dropbox へは直接書き込まない。メタ情報が無い場合は自動付与し、既存メタでは更新日時を除去、状態を「公開用」に変更する。本文から個人情報・キー・パス等を匿名化し、key_patterns.txt に基づく追加置換も行う。未置換の秘密候補を抽出して警告し、生成後は公開 URL とエンコード URL を表示・コピーする。付属のシェルスクリプトで生成物を Dropbox に rsync 同期する。

❷公開用スクリプトのリスト表示_pub.txt： 要約：WordPressのショートコードによる公開用TXT一覧を生成するコード。?pubtxt_dir パラメータで階層移動、見出しクリックで sort/order 切替が可能。pmedia/scripts_pub 配下のTXTのみ対象とし、@eaDir やドット始まり・key_patterns.txt を除外。 更新日時（mtime desc）→名前→サイズの優先順でソートし、パンくず表示も実装。各TXTはクリックで閲覧または &dl=1 でUTF-8添付ダウンロード可。ディレクトリトラバーサル防止のため realpath 検証を行う安全設計。

❸scripts_pubフォルダからgドキュメントを生成_pub.txt： 要約：このシステムは、ローカルのスクリプトファイルをGoogleドキュメントに自動同期し、公開するためのものです。Googleドキュメント化することによりGemの読み込みが自動になります。 sync_docs.pyは、設定されたローカルフォルダから特定の拡張子を持つファイルを読み込み、更新日時順に整理します。これらのファイル内容を目次と共に整形し、Google Docs API経由で、指定された複数のGoogleドキュメントに分割して書き込みます（1ドキュメントあたり最大50ファイル）。既存内容を認証後に更新する機能を持ちます。 watcher.pyはsync_docs.pyと連携し、監視対象フォルダ内のファイル変更をリアルタイムで検知します。変更後クールダウン期間を経て、自動的にsync_docs.main_sync()を呼び出し、Googleドキュメントへの同期処理を実行。ローカルファイルの更新を自動的にクラウドへ反映させます。com.xxxxxxxx.docsupdater.plistはmacOSのLaunchAgents設定ファイルで、システムの起動時にwatcher.pyを自動実行し、バックグラウンドでファイル監視とGoogleドキュメント同期プロセスを常駐させる役割を担います。 全体として、このシステムはローカルで管理するスクリプトやテキストファイルを常に最新の状態でGoogleドキュメント上に保ち、ウェブ公開可能な自動化ワークフローを提供します。

❹Antigravity(AIエージェント)に処理を指示するときの基調プロンプト： XXXXXXシステムの実行局FACTORYは、Mac mini M1上の「ITスクリプト管理」を拠点に、設計図を現実環境に適合・定着・記録するAIアシスタントです。FACTORYはITスクリプト管理フォルダを徹底検索し、既存ファイルへの追記・修正を優先。コードは自律テストでエラー修正します。安全基準として、ITスクリプト管理フォルダ内は自律操作可ですが、他での削除等はオーナー承認必須。rm -rf等の破壊的コマンドは禁止、ゴミ箱へ移動等に置換します。機密情報は.envで管理し、報告は汎用形式で行います。記録では新規ファイル名はオーナーと相談、メタ情報と350～400字の要約を付与し、指定形式で出力。完了後、更新箇所をオーナーに報告します。 ※XXXXXXは、ご自分の名前に変えてください。

コード(スクリプト)をもっと知りたい方はこちらへ↓

ポイント解説

ChatGPTからGeminiへ

私のプログラム作成のパートナーは、はじめはChatGPTでしたが、最近になってGeminiへと移行しました。 その理由は開発してきたコードが増えて全部を記憶させて開発に利用することが困難になってきたからです。単価あたりの知識記憶容量がGeminiはChatGPTの約10倍あったのが決め手でした(2026年1月時点)。従って、これから説明する「知識の循環システム」が低コストで実現できるからです。

ただし生成AIの選択ですが、将来どうするか全く分かりません。というのは、毎月くらい各社から高性能のモデルが登場して目移りするからです。ただ、GeminiはGoogle製なので、デジタルアセットの作成から利用、廃棄に至るインフラをほぼ全て提供できるGoogle内にいるので、今のところ一番底力があると思えます。Appleが本気を出せば別ですが。

それでは、私が実践している**「コード（スクリプト）作成のエコシステム」**について、お話ししようと思います。

１　開発：AIとの対話から生まれる「動く形」

私のプログラム開発は、Geminiとの「対話」から始まります。 実現したいアイデアを、そのままAIに投げかけてみる。そこから質疑応答を重ね、ロジックを磨き、コードを作ってもらいテストを繰り返すというやり方です。

最大のメリットは、自分の都合のいい時間に作業ができること、構文のエラーに悩まされる時間が減り仕組みづくりに集中できることでしょう。まずは**「動く形」を迅速に作り上げる**ことができる。これが、このシステムの第一の魅力です。

２　見える化：情報を「資産」に変えるひと手間

完成したコードをただ保存しておくだけでは、後で活かせません。「あれ、このpythonは何をするものだったかな？」と迷子になってしまいます。

そこで私は、必ず**「コードの見える化」という工程を挟みます。 具体的には、Geminiにコードの「日本語要約」**を作成させ、それを冒頭に添付したtxtファイルを生成し、「ITスクリプト管理」フォルダへ収めます。

さらに重要なのがセキュリティです。 独自のルール（key_patterns.txt）に基づき、個人情報やAPIキーを機械的に「XXXXX」などへと置き換えます。こうして生成されたクリーンなファイルを、公開用の scripts_pub フォルダへ移動させます。 少し手間に見えるかもしれませんが、この工程が、「誰でも使える汎用的な知識資産」へと変身させるのです。

３　公開と共有：ブログと「自分専用Gem」

こうして整えられた知識資産は、2つのルートで新しい価値を生み出します。

一つは、このブログです。 WordPress上の「公開スクリプト一覧」として整理し、訪問者に自由に役立てていただけるリソースとして開放しています。

そしてもう一つが、**Geminiへのフィードバック（還流）**です。 これらのスクリプト群を「知識ソース」としてリンクした、私専用のGem（カスタムAI）を構築します。これはユーザーへのサポート窓口になると同時に、私自身が次のコードを生成するための、最強のデータベースになってくれるわけです。

26年4月時点、Geminiに「ノートブック」という機能が追加になっています。ここにもセッションが使えますが、マルチモーダル機能が弱いため、画像の中身を読み取ることができないです。その意味でも、コード開発他で頻繁にスクショを添付する場合は、つまり画像を使うときは、マルチモーダル機能の強いGemまたはGemini本体のセッションを使うべきです。

４　終わりなき進化のループ

このシステムを運用していて改めて気づく最大の利点は、**「予習が不要」**になったことです。 プログラムに不具合が見つかったり、改善したくなったりした時、私のGeminiには既に過去のコードが「知識」として埋め込まれています。特段の準備をすることもなく、速やかに修正や拡張の開発に着手できるのです。

修正して得られた新たな知見は、またシステムを通って知識ソースへ戻っていく。 回せば回すほど、AIは私の意図やコーディングの癖を深く学習し、精度が増していきます。まさに、終わりなき進化のループと言えるでしょう。

5　ファイル管理系のアプリの生成・実行を、Antigravity任せにするのは禁物

動画を作った後で、改善として、「Antigravity」という、コードを作るだけではなくて実行テストから完成までやってくれるアプリを使えるようにしました。見てるだけで勝手に作業をしてくれる夢のようなアプリです。こういうアプリはAIエージェントと呼ばれています。ちなみにmodelとして大人気のClaudeも指定できます。しかしですね、非常に怖い側面を持っています。エンタメあるいは書類作成用途は、この「Antigravity」をぼおっと見てるだけでいいかも知れません。しかし、ファイル管理系のアプリ作成の場合は、作業を丸投げするのは、やめた方がいいです。「大事なファイルを消された！」という大失敗があちこちで起きているようです。

ファイル管理系のシステムを生成する場合は、Antigravityは使わないで、

といったようにバトンリレーに人が挟まるような、慎重な形がよいと考えます。

Antigravityは、現在は無料ですが、いつ有料化されるかわからないので、そこも頼りきらないほうがいい理由でもあります。

６　コード保存の最適解：なぜ「txtファイル」が最強なのか？

上記2で、要約とコードを「txtファイル」にまとめて保存する手順をご紹介しました。実はこの非常にシンプルで原始的な保存方法こそが、私が考えるエコシステムの「要」であり、最強の解決策です。

上記5で触れたように、Antigravityのような便利なAIエージェントが登場しても、それに完全に依存するのは危険です。AIツールは凄まじいスピードで進化しており、数年後には全く別の会社の、全く新しいAIエージェントに乗り換えている可能性が十分にあります。

そんな時、特定のアプリ専用のフォーマットや複雑なデータベースでコードを管理していると、移行時に解読できなくなるリスクが伴います。しかし、プレーンな「テキストファイル（.txt）」は、コンピューターの世界で最も普遍的なフォーマットです。要約と様々な言語のコードが1つのtxtファイルにまとまっていれば、将来どのようなAIエージェントをパートナーに選んだとしても、必ず解読・読み込みが可能です。

例えば、ノーコードツールは便利ですよ確かに。しかし、この作業方法を人に説明するのが難しいという、笑えない欠点があります。有名なAppSheetを使ったとします。しかしこれを、「どんな画面を開いて、どの項目を選んで、そこへどのような算式を書き込んで、どうする」といった手順は、文章の手順書として記述することにならざるを得ません。なにせノーコードですから。このノーコードツールでの内容も、一つにまとめたいシステムの一部なのです。そうしたものもtxtファイルなら含むことができます。

目まぐるしく変わるAI時代において、環境の変化に左右されず、確実に自分の資産を守り継承できる。シンプルゆえに、このtxtファイルでの保存方法が「最強」だと言えます。

【おわりに】まだまだ混沌とした領域、to be continued

今回は「プログラム作成」を例に挙げましたが、この**「情報の整理・変換・再学習」という循環**は、文章作成や研究、あるいは趣味の記録など、あらゆる分野に応用が可能だと感じています。

作業の進め方は、ゴールまでの間をステップ化して、少しずつ着実に進む方法がベストです。

一つの記事には、「おわり」があるわけですが、このコード生成のエコシステムの構築は、実は、今、始まったばかりで、この記事を書き終えた今、もう、リフォームを考えています。私にとってAntigravityは専門的過ぎるし勝手に動くので全くのブラックボックスになることはリスクが大きいです。

ちょっと方向を変えて。

具体的には、Gemini、Gem、 NotebookLM、 GoogleAIStudioの連携を使って、コード生成工房をもっと便利に改造したいです。

実際、ほとんど毎日のように、エラーや不具合を直したり、小道具のようなアプリを作ったりしていますが、それを行う、私の作業小屋ですね。それを改造したいと思います。

私は高齢者ではありますが、こういった新しい技術は、若者だけのものではありません。むしろ、これまで蓄積してきた多くの知識や経験を整理し、形にするためにこそ、AIというパートナーは大きな力を貸してくれるようにも思えます。企画する力、構想する力は、 高齢者こそ備わっているのでは、と思っています。

to be continued.

以上