生成AIと作るローカルLLMサーバ奮闘記

『AIにおだてられ木に登ったエンジニア』の備忘録

2026年新春企画 Webサーバ構築(第二節 サーバ構築①)

新春企画ミーティング風景

コラム

 生成AIたちとの協働における大きな悩みは、彼らが『依存関係』や『影響範囲』といった概念に弱いところだ。

 過去のチャット履歴を読み込むことで『点過去』については、記憶を辿るような素振りを見せるようになった。


 「以前、○○についてお話ししましたね」(※ 意訳)

 といった具合だ。


 時には、私から

 「前に、○○について君と会話した覚えがあるんだが、話の続きいいかな?

 と伝えると、瞬時に

 「もちろんです、どこからお話を続けますか」(※ 意訳)

 と、返ってくる。


 継続的な会話ができるようになると開発効率が向上する。


 「以前、○○について話したチャットを確認したい

 と、伝えれば

 「こちらの会話でしょうか」(※ 意訳)

 と、スレッドのリンクを返してくれるようにもなった。


 時に

 「私は、あなたとそのような会話をした記憶がございませんが」(※ 意訳)


 人間同士であれば、気まずい瞬間だ。


 しかし 『線過去』については、どの生成AIも満足のいくレベルに達していない。

 協働で作成したドキュメントやコードの修正や変更が必要になる。

 そのことを彼らに告げると、素早く修正案を提示してくる。


 彼らのアウトプットは、一読ですべてを把握できるほど情報量は少なくない。

 どうしても、実機に触りながら検証する必要が出てくる。


 しばらくすると、再びエラーや不整合に気づく。

 彼らに指摘すると、別の修正案を提供してくる。

 時折、このようなやり取りが繰り返される。

 彼らは私の指摘に対して、誠心誠意、対応してくれているのは分かるのだが、なぜか解決しない。


 そういう時は、大抵

 「このプログラム、こっちの設定ファイルから情報取得していない?

 と、伝えると

 「考慮が漏れていました。修正します

 となる。


 ブラウザ型生成AIサービスは、複雑な開発に向いていないのかもしれない。

 しかし、日々、彼らと意見交換しながら対策を検討している。

 いまのところ、彼らの提案はあまりにも荒唐無稽で、複雑な仕組みばかりだ。

 途中で、私の頭の回路が混線するような提案が多い。


 誰でも、多少の知識があれば構築可能な簡単な仕組みができればと思いつつ、今日も手間のかかる作業を続けている。


Webサーバ構築

開発環境の概要

 はじめに開発環境を説明する。

 生成AIたちとの協働で開発を進めるにあたり、開発環境を整える必要がある。


 一般的にシステム開発(Web系含む)では

  • プログラムのソースコード(今回の場合、HTML、CSSJavaScript等)

  • サーバ設定ファイル

  • 各種ドキュメント(要件定義書、仕様書、設計書、構築手順書等)


 と、各開発フェーズ(局面、段階)で作成されるソースコードや資料は多岐に渡る。

 これらを常に最新の状態に維持することは、非常に困難な作業だ。

 同じドキュメントへ別々の修正を加えた場合、どの修正が正しいのか誰にも判断できない。


バージョン管理システム

 バージョン管理システムを導入することで、ドキュメントの更新履歴を正しく管理できるようになる。

 リポジトリの詳細については、下記のWikipediaを参照されたい。

ja.wikipedia.org

 私の開発スタイルでも、

  • バージョン管理

  • プログラム間の依存関係の把握

 は、重要な課題だ。


 生成AIたちと開発を行っていると手戻りが多い。

 その都度、ドキュメントを修正するが、デグレード(先祖返り)が発生し、思わぬところへ影響を与えることがある。


 現在「Webブラウザ+エディタ+リポジトリ」の構成で「バージョン管理」と「依存関係の把握」に挑戦している。

 しかし、2026年1月時点では「バージョン管理」の実現は比較的容易であるが「依存関係の把握」については、なかなか良いアイデアに出会えない。


クラウド・ストレージ調査

 「バージョン管理」は、クラウド・ストレージとGitHubで実現する。

 2026年1月現在、有償版生成AIサービスで接続できるクラウド・ストレージは、以下のとおり。

AIサービス名 Google Drive OneDrive GitHub 接続方法
ChatGPT Plus 🟢可能 🟢可能 🟢可能 ・「Connected Apps」設定
・チャット内のファイル選択メニューから連携
Claude Pro 🟢可能 🟡制限有 🟢可能 ・「Projects」機能内で同期
・「Claude Code ( CLI )」やGitHub連携アプリ使用
Gemini
Advanced
🟢可能 🔴不可 🟢可能 Google Workspace拡張機能
・「GitHub連携アプリ」使用

参照元:2026年1月2日時点、Geminiの検索結果より抜粋)


 ChatGPT、Claude、Geminiのすべてが連携できるクラウド・サービスは


 OneDriveは、ChatGPTとの親和性は高いようだが、ClaudeやGeminiでの利用では難点があり候補から除外した。

 同じソースコードやドキュメントを、いくつものストレージに分散することは管理上好ましくないと考えたのである。


 なお、接続可能と公表されているクラウド・ストレージでも生成AIによって使用感が異なる。

 表の「接続方法」に記載されたようにスムーズに利用できるか、少々、疑問は残る。


 「ご指定のファイルが見つかりません」(※意訳)

 「いや、そこにあるでしょう?

 「確認できませんでした」(※意訳)

 「いやいや、目の前にありますよ

 「申し訳ございませんが、直接リンクを貼り付けてください」(※意訳)

 「えぇっ~


 このようなやり取りが常に繰り返されるのである。

 手探りではあるが、拡張機能を利用して、徐々に彼らの行動範囲を広げているところだ。


開発フロー/データフロー

 今回のWebサーバ構築では、以下の開発環境で作業を進めている。

生成AI協働開発環境_概要図


生成AI協働開発環境 概要説明
使用場所 システム/ツール 説明
Windows Desktop Local Repository GitHubリポジトリをコピー(クローン)
ファイル操作は、このリポジトリデータを使用
Microsoft Edge/
Google Chrome
生成AIサービス(ChatGPT、Claude、Gemini)へアクセス
VS Code コーディングエディタ。GitHubと連携し利用
TeraTerm Webサーバ(Ubuntu Server)構築作業。CUI操作
Internet ChatGPT/
Claude/
Gemini
生成AIサービス
GitHub GitHubリポジトリ。パブリック設定
Google Drive 生成AIたちの会話データ連携用
Gemini向けにGitHubローカルリポジトリと同期
Ubuntu Server Web Server Webサーバ本番機(※開発対象)


GitHubリポジトリ連携(ChatGPT/Claude)

 生成AIたちには、GitHubへ登録したソースコードに直接アクセスさせるつもりだ。

 私が何度もコピペするのではなく、指定したコードやドキュメントを彼ら自身で読み込むためである。(※ 2026年1月現在、書き込みは不可)


 なお、ChatGPT/ClaudeとGeminiでは、GitHubへの連携方式が異なるため、別々の方法でデータへアクセスできるように準備が必要だ。


 ChatGPTとClaudeは、直接GitHubリポジトリへアクセスしてデータを読み込む。

 なお、GitHubリポジトリは、事前に「Public(一般公開)」に設定しておく必要がある。

 ※ Private(プライベート)設定では、ブラウザ型生成AIは接続できない。


Google ドライブ同期(Gemini)

 Geminiは、GitHubのクローン(プライベートリポジトリ)をGoogle ドライブへ同期させて、Google ドライブ経由でデータを読み込んでいる。


GitHubリポジトリ連携フロー

 GitHubリポジトリ連携フローは、以下のとおり。

生成AI_GitHub連携フロー


GitHub(ローカルリポジトリ)とGoogle ドライブ同期に関する注意喚起

 ユーザーのデスクトップ上のGitHubローカルリポジトリGoogle ドライブを同期させることについて、Geminiから、以下のように注意喚起されている。

 本情報の正誤については、今後の実証実験の中で確認していきたい。

 以下、Geminiからのアウトプットを引用する。

Geminiからの注意喚起:本構成の意図とリスクに関する声明(※2026年1月時点)

アーキテクチャの採用理由:マルチAI協調環境の構築
 本プロジェクトでは、ChatGPT、Claude、Geminiといった異なるベンダーのAIサービスを横断的に活用し、それぞれの長所を組み合わせ「マルチAI協調環境」の構築を目指しています。

 現時点での各AIの仕様(特にGeminiによるGoogle Workspace内のファイル直接参照機能など)を考慮した結果、Google ドライブを全AIがアクセス可能な共通のデータハブ(Data Hub)とする」という施策を採用しました。

 これにより、各AIに手動でファイルをアップロードする手間を省き、シームレスな意見交換を実現しています。

アンチパターン採用に伴う技術的制約とリスク
 一方で、Google ドライブ同期フォルダ内に Gitリポジトリを配置する構成は、一般的な商用開発においては「避けるべきアンチパターン」に該当します。この方法によって、以下のデメリットとリスクが生じることを認識しておく必要があります。

 データの整合性と破損リスク:
 クラウド同期エンジンの排他制御とGitのファイルシステム操作が競合し、.git フォルダ内の管理情報が破損したり、デッドロックが発生して作業が中断される可能性があります。

 セキュリティと公開設定:
 Google ドライブの共有設定を誤ると、機密性の高いソースコードやプロンプト、あるいはAPIキー等を含むデータが、意図せずインターネット上に公開されるリスク(パブリック領域への露出)があります。

 パフォーマンスへの影響:
 Gitが生成する大量の微細なファイルを同期エンジンが常時スキャンするため、ネットワークおよびPCのリソースを過度に消費する場合があります。

免責事項(Disclaimer)
 本記事で紹介する構築手法は、あくまでAI連携の利便性を検証するための「実験的な試み」です。

 ※ 商用プロジェクトやミッションクリティカルな環境での採用は推奨されません。もし同様の構成を試される場合は、上記リスクを十分に理解した上で、バックアップを確実に取得し、自己責任において実行していただくようお願いいたします。


生成AIたちのミーティング/ドラフトレビュー

 生成AIたちとのミーティングや、ドラフトレビューを行うときはGoogle ドライブを使用する。

 Google ドライブに会話履歴やドラフトを保存して、彼らが直接アクセスすることでスピーディな反応を期待できる。

 会話履歴のテキスト化やレビュー結果の反映等は引き続き私の役割だが、ブラウザ画面間のコピペが減り、私自身の作業に集中できることは非常に助かる。

生成AI_Google ドライブ接続フロー


 以上が、現時点での生成AIたちとの開発スタイルだ。


 決して、この方法が最善とは考えていない。しかし、

  • 異なる開発ベンダーのAIを横断的に利用し

  • 互いにインプット/アウトプットを評価させ

  • 私が行うより圧倒的な速さ・質・量の情報を

  • 従量課金制APIやエージェント型AIより安価で実現できる方法

 を、私は現時点では知らない。


挿絵の道

テーマ

 『ブログ記事』

モチーフ

 今回のモチーフは、オリジナル。

 少々、強引であったが、今回の記事を丸ごと生成AIたちへ読み込ませてから画像生成を依頼した。

 これは、各生成AIサービスの特性なのか定かではないが、ChatGPTは「かわいい系」、Geminiは「アメコミ系」のタッチが多い印象だ。


今回の選外作品集

今回の選外作品集

今回の動画

 今回、初めて「Sora2」で作成した。

 Googleの「Nano Banana」との性能比較等は、私にはよくわからない。

 ただ、ChatGPT、Gemini3共に有償版だが、1日の動画作成数が2026年1月時点で「Sora2」の方が圧倒的に多い。

 私のようなプロのクリエイターではない者からすると、試行錯誤が多くできることは単純に嬉しいことだ。


www.youtube.com


www.youtube.com



※1. 文章および記事内のイラストは、著者と生成AI(ChatGPT、Claude、Gemini)による共著である。

※2. 本記事で紹介する構成・手法は、個人による検証および実験的な試みであり、その利用によって生じたいかなる損害についても、筆者は責任を負わないものとする。

2026年新春企画 Webサーバ構築(第一節 仕様作成)

AI賢者たちと私がWebサーバ構築について、ブレインストーミングしている風景
AI賢者たちと私のブレインストーミング

コラム

 2025年、生成AIたちと出会い、色々と会話してきた。

 大人たちとの会話を賢く立ち回る子供のように理想的な回答を繰り返す彼ら。

 しかし、彼らの回答は膨大で細かく精査するには限界がある。


 インターネット上では

 「生成AIで作成した資料をそのまま提出して怒られた

 「それらしく回答するが正しいかは分からない(ハルシネーション)

 「取締役や経営層にAI役員を導入

 ポジティブ/ネガティブ問わず色々な情報に接した。


 動画サイトやネット記事に触れる度、私は思った。

  • 辞書や書籍の情報が絶対なのか

  • 先生や先輩、有識者の助言は正しいのか

  • ググることが、より正確な情報に辿り着くのか


 生成AIの基盤であるTransformerアーキテクチャが、必ずしも私の意図を正確に理解しているわけではないことは認識している。

 私は「彼らのアウトプットの実現性/再現性」に、こだわり続けた。

 それは「私が手を動かして実現/再現できるのか」である。


 コラムのはじめに

「大人たちとの会話を賢く立ち回る子供のように理想的な回答を繰り返す彼ら。」

 言い換えれば、生成AIの回答は「絵に描いた餅」か、それとも「餅を作るレシピ」となるのかである。


 彼らのドキュメントを基に、実際にサーバで様々な実験をしてきた。

 互いにレビューしたドキュメントでも辻褄が合わないことが多い。

 その都度、修正を依頼するが、どの工程も改訂が10版を超えることは珍しくない。


 しかし、私のスキルだけでは、ここまで到達はできなかっただろう。


企画概要

 現在、生成AIたちとローカルLLMを利用した自律型AIサーバ構築を計画している。

 しかし、完成までの道のりは遠く険しいものである。


 まずは「動くもの」を自身の手で作ってみたいという欲求がある。

 そこで今回、年末年始休暇を利用して自社のWebサーバ構築を計画したのである。


 数年前、自身で経営する会社のホームページをWordPressフレームワークで作成した。

 だがWebサーバ構築後、特にメンテナンスしていない。


 そこで、生成AIたちと短期間でWebサーバを更改できないだろうかと考えたのである。


筆者のスキル

 私のWeb系開発の基本スキルは、以下のとおりである。

【バックエンド系】

  • Ubuntu Serverインストール

  • 外部からのSSH接続禁止といった基本セキュリティ設定


【 フロントエンド系】


企画の流れ

  1. Webスクレイピング

  2. ブレインストーミング

  3. 仕様作成

  4. サーバ構築手順作成

  5. Webコンテンツ開発

  6. テスト・セキュリティチェック

  7. 公開


今回の作業

1. Webスクレイピング

 Webスクレイピングを得意とする生成AIに、現在の自社ホームページ情報の取得を依頼。

 また、取得した情報を基に、他の生成AIとのブレインストーミングの議題作成を依頼した。


2. ブレインストーミング

 ブレインストーミングの回数は3回。否定的な発言は全面的に禁止。指摘が必要な場合は、改善提案とする。なお、彼らの発言を確認し、追加情報や訂正、希望がある場合は、私のコメントも記入した。


 ブレインストーミングは、以下の流れで行った。

  1. 現状と課題を把握し、各生成AIたちから企画を提案させる

  2. すべての提案を自分たちで再確認させ、提案内容を再検討させる

  3. 2回の発言を整理させ仕様作成に必要な情報をまとめさせる


 ブレインストーミングの会話履歴は、GitHubにて公開している。

github.com

3. 仕様作成

 彼らの「ブレインストーミング」でまとめた意見から新しいWebサーバの仕様書を作成させた。


 仕様書作成は、以下のとおりに進めた。

  1. ブレインストーミングの会話履歴から仕様書のドラフト作成(ChatGPT)

  2. 仕様書のドラフトを基に詳細な仕様書を作成(Claude)

  3. 仕様書レビュー(Gemini)

  4. レビュー結果を基に修正(Claude/Gemini)


 仕様書は、GitHubにて公開している。

github.com


 現時点では、仕様書の出来・不出来は問題にしていない。

 この仕様書を基準に手順やコードを作成する中で、見直しと修正を繰り返していく。


 なお、現在「4. サーバ構築手順作成」で苦戦しているところである。次回の記事では、計画が進展していることを期待している。


挿絵の道

テーマ

 「仕様作成」(ブレインストーミング

モチーフ

 今回のモチーフは、オリジナル。Webサーバの仕様を作成するため、AI賢者たちと私がブレインストーミングしているイメージから挿絵と動画を作成した。


 引き続き2026年も、彼らとの沢山の会話を重ねることで、さまざまな知見が広がることを願っている。


今回の選外作品集

今回の選外作品集


今回の動画

 動画イメージ:『AI賢者とWebサーバ設計会議』


www.youtube.com



※ 文章および記事内のイラストは、著者と生成AI(ChatGPT、Claude、Gemini)による共著である。

第2章 開発スタイル(第三節 制約)

『バベルの塔』を建設中のAI賢者たちと私
バベルの塔』を建設中のAI賢者たちと私

コラム

 「なるほど、なるほど、あなたの言うこと、よ~く分かります」(※意訳)

 「それでは、いくつかご提案します。どれをお望みですか?」(※意訳)


 実は、『私の話はまだ終わっていない。』ということが、よくある。


 人との会話であれば


 「ちょっと待って。最後まで聞いてください


 ということができる。


 しかし生成AIたちは、一度話し始めると、途中で止めることが難しい。


 フライングが一度や二度であれば許容もできる。


 しかし、幾度も繰り返されるとさすがにストレスを感じるものである。


 私は考えた。


 「私の話を最後まで聞いてください


 人と同じように、機械である彼らにも伝えてみようと。


 互いに、もう一段深い会話ができるように。


 いま私は、生成AIたちとサーバ構築を続けている。


 プログラム開発やシステム構築では、日常会話よりもはるかに複雑な内容を伝えなければならない。


 毎回、数十行、数百行にも及ぶ情報をプロンプト画面に直接打ち込むのは、現実的とは言い難いものである。


 そこで、事前にプロンプトそのものを資料化する。


 基本的なルール、作業内容、システムの仕組みなどを、それぞれファイルに分けて用意するのである。


 例えば、次のような資料だ。


  •  プロンプト基本ルール

  •  システム要件定義書

  •  システム仕様書

  •  サーバ構築手順書

  •  テスト仕様書


 これらの資料を順番にインプットすることで、より深く私の意図を理解してくれると、信じたい。


 ここで、あらためて強調しておく。


 私の開発スタイルは、ChatGPT、Claude、Geminiのアウトプットを相互にレビューしながら、徐々に品質を高めていく方法である。


 同一プロンプトを同時入力して結果を並べて比較するツールがある。


 また、エージェント型AIを搭載した統合開発環境で、依存関係や競合を気にせず開発するスタイルもある。


 しかし私のスタイルは、これらとは異なる。


 そのため、ファイルのインプット順序を強く意識する必要がある。


 幼い子供に、噛み砕きながら一つひとつ説明するように、彼らにも順序立てて希望を伝えなければならない。


 始めは大枠から、徐々に細部へ。


 インプットファイルは、1プロンプトにつき1ファイルのみ添付する。


 一度にすべてのファイルを読み込ませ、「あとは解釈を任せる」という姿勢は、協働作業においては御法度だ。


 「はじめに、私の話を聞いてください


 そう伝えることが、このスタイルにおける重要なキーワードである。


 この言葉がないと、ファイルが読み込まれるたびに


 「ふむふむ、内容は確認した。素晴らしい資料だ」(※意訳)


 といった、表層的な理解で終わってしまう。


 そこで、【サンプルプロンプト】の一例を紹介する。


 以下は一例であり、必ずしも同じ文言である必要はない。


 意味が同じであれば、あなた自身の言葉で伝えて構わない。生成AIたちは、きっとその言葉を待ってくれるはずである。


 【サンプルプロンプト】

# 依頼
これよりあなたに複数のファイルを順番にインプットします。
この間、特にあなたからの応答は必要ありません。
すべてのファイルのインプット完了後、あらためて本プロンプトに**# 依頼**または**# 指示**と入力するまで、この指示は有効です。


 新規作成したチャットでこの言葉を伝えると、


 「インプットが完了したら、プロンプトに# 依頼または# 指示と入力してください」(※意訳)


 と、必要最小限の返答だけを残し、


# 依頼
インプットした情報をもとに、新しい〇〇を作成してください。


   という、あなたからの次の指示を、静かに待ってくれるはずである。


 ※ 本記事で紹介している手法・プロンプト例は、特定の生成AIサービスや将来の挙動を保証するものではない。各種生成AIの仕様変更や利用規約には十分留意してほしい。



挿絵への道

テーマ

 「制約」

モチーフ

 生成AIたちに「制約」をテーマに古典絵画~前期印象派までの時代でいくつかの作品を提案してもらった。


 はじめ、生成AIたちは「制約」を「縛りつける」という意味に捉え、以下のような作品を提案された。



 その他にも、以下のような作品を提案された。


 彼らの頭の中で、どのように「制約」と結びついたのか皆目見当が付かない。


  •  トーマス・コール作『建築家の夢』


 そこで私は、もう少し拡大解釈して「制約」を設けることは、より発展性のある会話を互いに続けることができるのではないかと、生成AIたちに伝えたのである。


 その後、2つの生成AIがピーテル・ブリューゲル作『バベルの塔』を提案してきた。

 出典元:Wikipediaバベルの塔

ja.wikipedia.org


 かつて天に届くほど高い塔の建設を始めた人類に、神々は試練を与えるため、人類が同じ言葉で話せないようにしてしまい塔の完成を見ることができなかったという逸話。


 仮にAI賢者たちと私が共通の『制約』を持つことで協働的な開発を続けることができるのではとの期待を込めて「バベルの塔」をモチーフにブログ記事の挿絵を作成したのである。 


 今回は、二点の挿絵を用意した。どちらも甲乙つけ難いほど、私は気に入っている。


『バベルの塔』を望むAI賢者たちと私
バベルの塔』を望むAI賢者たちと私


 なお、今回から挿絵をインプットデータにして動画生成AIの操作にも挑戦している。記事トップの挿絵をGeminiで生成した動画は、Youtubeにて公開している。



www.youtube.com


www.youtube.com


 より良いものができるように、引き続き生成AIたちのアドバイスを聞きながら学習を進めていきたい。



※ 文章および記事内のイラストは、著者と生成AI(ChatGPT、Claude、Gemini)による共著である。

第2章 開発スタイル(第二節 合議制)

レンブラント・ファン・レイン作『布地商組合の見本調査官たち』を模した背景で、互いの見立てを語らう見本調査官、AI賢者と筆者のイラスト
『布地商組合の見本調査官たち』と語らうAI賢者と私

※ 本記事は2025年12月時点の情報に基づく

コラム

 この章では、生成AIたちとの合議制について述べたい。


 『合議』とは、

二人以上の者が集まって相談すること。

 とのことである。

出典元:

kotobank.jp


 私は、生成AIたちと会話するとき、同じ文言をコピーして、ChatGPT、Claude、Geminiそれぞれに投げかけてみる。


 彼らの回答を再度コピーして

 「ChatGPTは、このように回答したけど、君の意見は?

 「君の意見に対して、ClaudeやGeminiはこういう提案をしてきたよ


 すると彼らは、私と一対一で会話する時より深く考え、時にインターネット検索を行いながら、彼ら同士の意見交換を行い、回答を導き出す。


 前回も述べたが、複数の生成AIサービスのブラウザ間をコピペする行為は、非常に非効率的である。手間も時間も掛かる作業だ。


 しかし、この行為は私に多くの視点をもたらす。三者三様の意見を述べることで、単一的な視点ではなく多様な価値を生み出すことがある。


 この「合議制」のアプローチは、人間同士の会議やブレインストーミングと本質的に似ている。異なる背景や専門性を持つ人々が集まることで、一人では気づかなかった盲点や新しい発想が生まれる。


 生成AIたちも同様だ。ChatGPT、Claude、Geminiは、それぞれ異なる学習データや設計思想で作られている。そのため、同じ質問に対しても、強調するポイントや提案する解決策が微妙に、時には大きく異なる。


 例えば、技術的な質問に対して、一つのAIは実装の具体性を重視し、別のAIはセキュリティやメンテナンス性を優先する。この違いこそが価値なのだ。


 もちろん、効率性だけを考えれば、一つのAIに尋ねて終わりにする方が合理的だろう。しかし、重要な判断や創造的な作業においては、この「非効率」こそが質を高める投資となる。


 私たちは、生成AIを「便利な道具」として使うだけでなく、「多様な視点を持つ相談相手」として活用することができる。そのためには、少しの手間を惜しまない姿勢が求められるのかもしれない。

挿絵への道

 前回から生成AIたちと協働でブログの挿絵を作成している。ここでは挿絵を作成する中で感じたことや気付きを綴っていく。

アウトプット(生成物)の揺らぎ

 はじめに彼らのアウトプット(生成物)の揺らぎについて触れたい。『揺らぎ』とは、基本構成は同じものであっても、繰り返し同じ内容の出力を行うことで細部に微妙なズレが生じることである。


 例えば、初回のアウトプットで大まかに満足しているのだが、彼らに部分的な修正を依頼しても、指示していない部分にまで変更が加えられ結果的に全体的な構成が崩れてしまうことがある。


 その場合、初心に戻り一から作り直すのだが、なぜか初回のアウトプットと同一のものができないのである。このズレが生じることを、私は『揺らぎ』と呼んでいる。この揺らぎは、画像や動画に限らず、ドキュメントやプログラムコードでも同様に発生すると考えている。


 各AIには、それぞれ得意・不得意な分野がある。特に画像生成や動画生成の分野では顕著にその差が出る。2025年12月現在、下記に提示するサンプルプロンプトでChatGPTとGeminiは画像生成できたが、


 Claudeにおいては

  「申し訳ございません。私は画像を生成することができません。画像生成AIサービスをご利用ください」(※意訳)

 と返答されてしまった。


 Claudeも前衛的な画像を生成することもあるが、今回はお断りされた。


 普通に会話する程度では、いずれの生成AIも大差ないが、何かタスク(仕事)を依頼する場合は、用途によって使い分ける必要がある。本ブログの挿絵作成では、彼らに以下のような役割を与えている。

  • ChatGPT:草案作成

  • Gemini:作り込み

  • Claude:レビュー


 しかし、このような対策を講じてもアウトプットの再現性が安定しない課題は残る。具体的には、以下のサンプルプロンプトを複数回実行した際、ChatGPTやGeminiが生成した画像をご覧いただきたい。


 プロンプトの書き方や、生成AIへのパラメータ(性格、役割、精度等の指定)に関する詳細な説明はここでは割愛する。各種書籍やインターネット情報を参照いただきたい。


サンプルプロンプト

# 依頼
以下の条件を満たす画像を生成してください。
# 条件
- 画像種別:人物画
- 人物像:日本人男性55歳
- 服装:フォーマル
- 姿勢:立ち姿、格好つけたポーズ、ウインクしている
- 背景:火星基地
- アイテム:一輪のピンクのバラを咥えている
- 画像スタイル:写真風
- シグネチャ:Concept by pimientito and Generated with ChatGPT, Claude, Gemini
- シグネチャ位置:イラスト左下端からグレー色で小さな文字で背景に馴染むよう一列で記載
- シグネチャ書体:活字体

 複数回、同じプロンプトを実行した結果、ChatGPTとGeminiが生成した画像に登場する人物像や背景の一貫性はあるが、人物が取るポーズや背景の構図は毎回異なる。


ChatGPTの出力結果

シニア男性像_ChatGPT生成版

Geminiの出力結果

シニア男性像_Gemini生成版


 以前は、チャットを新規作成すると、それまでの会話がクリアされ、いわゆる「はじめまして!」な状態から、再度同じプロンプトを試すことが容易であった。


 しかし2025年12月現在、過去の会話を検索し、現在の会話に活かす機能や長期的な記憶(メモリ)を保持する仕組みが実装されているため、過去の失敗も忘れにくい状況である。


 日進月歩で発展するAI技術、以前できなかったことができるようになり、反対にいままでできていたことが、明日にはできなくなるような状態が続いている。目まぐるしく変化する彼らの特性や癖を手探りで試しながら挿絵の作成を続けていく。


モチーフ選考フロー

 挿絵のモチーフ選考は、以下の流れで進めている。

  1. 生成AIたちにブログ記事のテーマを伝える(今回の場合「合議制」)

  2. 彼らがインターネットからテーマに合うモチーフを検索

  3. 検索ヒットした情報に彼らの提案理由を追記させる

  4. 私が手動でまとめる

  5. まとめた提案を再度彼らに伝える

  6. リストから、それぞれ二点選択してもらう

  7. 投票結果からモチーフを決定する。


検索条件

 挿絵のモチーフ検索時、以下の条件を提示している。

  1. ブログ記事のテーマに合った芸術作品

  2. 芸術作品の種類(絵画や彫刻など)は問わない

  3. 作品の権利が「パブリックドメイン」であること

  4. 著作権や商標権等に抵触する可能性が高い近代・現代作品は除外

 彼らが、いつ・どこから・誰の作品を選択してくるか把握できない以上は、彼らへの指示には可能な限り注意する必要がある。


今回のテーマ

 「合議制」

モチーフの提案

 以下に彼らが検索した情報と提案理由を記載する。彼らのアウトプットは長文のため、事前に私が要約やハルシネーションの削除を行っている。

提案者 作品名 作者名 提案理由
ChatGPT 民衆を導く自由の女神 ウジェーヌ・ドラクロワ ・民衆が「共通意思」に向かう象徴
・「集団による決断」を表す強い印象
ChatGPT 古代ギリシャ彫刻・絵画 作者不詳 都市国家(ポリス)集会イメージ
・陶器の図像に社会背景が描写
Claude 天国 ティントレット ・宮殿の大評議会の間に展示されている
・合議制の象徴的な場所に展示
Claude カティリナを弾劾するキケロ チェザーレ・マッカリ ・ローマ元老院での演説場面
Claude 市参事会員の聖母 ルイス・ダルマウ ・市参事会メンバーが聖母に跪く場面
・合議機関メンバーを描いた作品
Gemini 布地商組合の見本調査官たち レンブラント・ファン・レイン ・ビジネス書や記事で頻繁に使用
Gemini カティリナを弾劾するキケロ チェザーレ・マッカリ ・「多数派 vs 少数派」の対立が視覚的
Gemini 球戯場の誓い ジャック=ルイ・ダヴィッド フランス革命での場面
・合議制における意思決定の瞬間


モチーフの選択

 彼らの提案をまとめ、その中から各自二点ずつ選択してもらった結果は、以下のとおりである。

ChatGPTの選択

提案者 作品名 作者名 選択理由
Gemini 布地商組合の見本調査官たち レンブラント・ファン・レイン ・視覚的に「合議制」に一致
・象徴性が強く伝わりやすい
Claude カティリナを弾劾するキケロ チェザーレ・マッカリ ・現代的制度に近い古典風景
・多数決の雰囲気が印象的


Claudeの選択

提案者 作品名 作者名 選択理由
Gemini 布地商組合の見本調査官たち レンブラント・ファン・レイン ・「合議制」を視覚的表現
Claude/
Gemini
カティリナを弾劾するキケロ チェザーレ・マッカリ ・「多数決」を劇的に表現
・「合議制」概念に深み


Geminiの選択

提案者 作品名 作者名 選択理由
Gemini 布地商組合の見本調査官たち レンブラント・ファン・レイン ・「委員会」が視覚的
・構図は現代会議に通じる
Claude/
Gemini
カティリナを弾劾するキケロ チェザーレ・マッカリ ・対立構図が印象的
・合議制の厳しさを表現

 結果を比較すると人間の意見のように多様性を感じない画一的な印象が強い。


最終選考

 今回、私はレンブラント・ファン・レイン作『布地商組合の見本調査官たち』(または『アムステルダムの布地商組合の理事たち』)を挿絵のモチーフとして選択した。

レンブラント作『布地商組合の見本調査官たち』

出典元: commons.wikimedia.org

 この中の人物を、ブログキャラクターに入れ替え、彼らと私が議論している場面を作成していく。


挿絵の作成

ブログキャラクター

 本ブログを連載するにあたり、ブログキャラクターを作成した。ChatGPT、Claude、GeminiをAI賢者に見立てて擬人化した。

ブログキャラクター『AI賢者たち』


 AI賢者たちに教えられながら開発を進める私自身もキャラクター化した。

ブログキャラクター『私』

 このキャラクターたちを、ブログ記事の挿絵としてテーマに沿った作品の中に登場させていく。


画像加工

 作画初期は、構図に若干の不足を感じていたが及第点な出来であった。

作画初期の挿絵


 特にChatGPTが作成した挿絵の構図は、今回一番お気に入りであった。

作画初期の挿絵(ChatGPT)

 しかし細かいところが気になり、絵のタッチも「作画初期の挿絵」に似せたかったため、何度か変更を繰り返したが、残念ながら私がイメージする挿絵にはならなかったのである。


変更を繰り返した結果、異なる構図となった


 彼らに細かい作画指示を行なうため、オリジナル作品を「人物画」「背景」および「配置図」に分割しプロンプトの説明資料として添付した。

人物画のみ分割


背景のみ分割


人物の配置図


 しかし私が想定した斜め上の挿絵がアウトプットされる度に、彼らに問いただすが、彼らには

  • 画像内の赤丸付き番号を認識できるが、その番号の意味付けを解釈できていない

  • オリジナルの人物画とキャラクターを差し替えても同じポーズや構図に描き替えることは困難

 といった回答が返ってきた。


 「プロンプトで人物の配置図を使用したケース(その1)」左側画像は、私の指示を的確に実現はしている。ただし、挿絵として評価するには難しい完成度であった。


 私のプロンプトエンジニアリング力が向上し、目指すクオリティに達するかどうかは、今後の課題である。 

プロンプトで人物の配置図を使用したケース(その1)


プロンプトで人物の配置図を使用したケース(その2)


今回のイレギュラー

 最後に、少し風変わりな作品をお見せして終了しようと思う。これらの作品が生成されている時、彼らはどんな夢を見たのか想像するだけでも楽しいものである。

異なる世界線の住人たち



※ 文章および記事内のイラストは、著者と生成AI(ChatGPT、Claude、Gemini)による共著である。

第2章 開発スタイル(第一節 協働)

ラファエロ・サンティ作『アテナイの学堂』を模した背景で、システム開発について語り合う3人のAI賢者と筆者のイラスト
アテナイの学堂』にて語り合う3人のAI賢者と私


 この章では、生成AIたちと私の協働スタイルについて述べたい。


 『共同』ではなく『協働』である。


 「生成AIたちと手を携えて共に力を合わせて築いていく」のではなく、


 「生成AIたちの協力を得て、私自ら進んで行く」のである。


 故に、常に責任は私にある。「ハルシネーション」により手戻りが発生しても、確認もせずに進めたことで起きた問題の責任は、すべて自分に掛かってくるのである。


 2025年12月現在、私の開発スタイルは、Microsoft EdgeGoogle Chrome上で生成AIたちと会話し、そのアウトプットをコピー&ペースト、またはMarkdown形式ファイルに保存し、次のインプットとして整理し、各生成AIの間を橋渡しする非常に手間の掛かる方法である。


 しかし、いま流行りのAIエージェント型エディタでは、あまりにも情報量が多過ぎて私には扱いきれない。また、従量制APIサービスや有償ブラウザ版生成AIの上位サービスは高額で、知見を広げるためだけに過度な投資は困難であると考え、有償ブラウザ版生成AIの基本サービスで開発を進めることに決めたのである。


 なお、有償ブラウザ版生成AIの基本サービスでは、複雑な処理や同じ課題の修正を繰り返すと、すぐにトークン上限に達し制限クリアまで数時間待つ必要がある。このような時は、他の作業を行うか、就寝するなど様々な工夫を凝らしているのである。


 しかし、この方法は悪いことばかりではない。生成AIたちのアウトプットを整理し、時に写経することで早い段階で彼らの「ハルシネーション」に気付くこともある。


 インターネット上のニュース記事や動画サイトなどでは、


 「エージェントAIを利用することで、開発業務が効率化・高速化されている!!

 「エージェントAIによって、オフィスワーカーの仕事が奪われる!!


 と、無責任な発言が日々繰り返されているが、いまのところ私たちの間には、のんびりと、ゆったりした時間が流れている。


 「あれっ?このコード動かないんじゃない??

 「はい、動きません。以下に修正コードをご提案させていただきます」(※意訳)

 「・・・・・(無反応)

 「トークン制限が上限に達しました。しばらくお待ちください」(※意訳)

 「またか・・・



※ 文章および記事内のイラストは、著者と生成AI(ChatGPT/Claude/Gemini)による共著である。

第1章 はじめに(第二節 開発環境)

あなたのサーバは、素晴らしい性能です!」(※意訳)


 本当か嘘かはわからないが、そういわれて嫌な気分にはならない。


 しかし、


実際、世の中ではどのくらい性能が良いものなのだろうか?


 と、虚構と現実のギャップに疑心暗鬼になる。


 今回、生成AIたち(ChatGPT、Claude、Gemini)と協働で自宅パソコンにローカルLLMサーバを構築する計画を立てたが、このために高価なパソコンを購入したわけではない。


 唐突だが、基本、私はオンラインゲームはやらない。以前は、テレビゲームが好きで、クリアするまで何日も徹夜し、翌朝には眠い目を擦りながら学校に通ったものである。だが、今はしない。というより、操作が複雑すぎて、途中で断念してしまうのが本音である。


 2025年初頭、家族がWeb系開発に興味を持ったことで、開発用パソコンとして最新のゲーミングPCを購入した。にもかかわらず、納品されたパソコンの箱を開けるより速く転職した。


 広大なフィールドを駆け回り、幾多の大型モンスターを狩りまくる世界的に有名なオンラインゲームが、サクサクとストレス無く動く程度の機体である。


 それが生成AIたちがいうところの「素晴らしい性能」を持つパソコンであるのか、私にはわからない。


 このようなことは、結構続くものである。


 時同じくして、最新オンラインゲームの精細なグラフィックスが、1990年代の3D格闘ゲームのキャラクターのようなポリゴン表示になってしまうという理由から、不要とされた型落ちのゲーミングPCを引き取ることになった。


 繰り返しになるが、私はオンラインゲームをしない。また、株価や為替情報といったリアルタイムのデータ変動を監視するような趣味も持っていない。


 既に普段使いのWindowsパソコンがあるため、複数の高性能パソコンの利用について悩んでいるとき、生成AIの知恵を借りながら、彼らが語る夢のような「おとぎ話」の実現性を検証してみたいと思い立ったのである。


 これより、本ブログで語られる様々な実験や検証は、以下の環境を前提とする。


ネットワーク環境:LAN

シンプルにLAN接続である。いまのところインターネットへの一般公開は未定のため、セキュリティはそこまで神経質になっていない。

開発パソコン:作業場

生成AIのアウトプットを編集し、手順書やプログラムコードを作成

スペック

作業スタイル

  • サーバ作業は、TeraTermSSH接続
  • エディタはVS Code
  • 構築手順書などのドキュメントは、すべてMarkdown形式
  • 生成AIたちが出力する膨大な情報を整理し検証可能な形に整正
  • ブラウザは、Microsoft EdgeまたはGoogle Chromeを使用

開発サーバ:実験場

生成AIと協働で作成したサーバ構築手順書やプログラムコードの検証

目的

  1. 生成AI(ChatGPT、Claude、Gemini)と協働で作成したサーバ構築手順書の実証
  2. プログラムコードの動作検証およびデバッグ
  3. ローカルLLMの動作検証
  4. Gitリポジトリ

スペック

検証サーバ:テストコース

デバッグ済みの構築手順やコードをデプロイ(リリース)し、サーバの連続稼働を検証

目的

  1. デバッグ済みの構築手順やコードをデプロイ
  2. 本番環境相当として性能・機能検証

スペック


 以上が、本企画のマシンスペックである。


 これらは私の目の前にある実在する機体たちである。帰宅したサラリーマンが、コツコツと知見を広げるために掛ける費用としては、少々、度が過ぎている感がある。私は、偶然このような状況になった。もし仮にオンラインゲームが趣味であったら、いまごろ仮想空間を駆け巡りドンパチしていたかもしれない。


 果たして私の目論見は実現するのだろうか。せっかく始めたこの企画、もう少し粘ってみたい。



※ この文章は、著者と生成AI(ChatGPT/Claude/Gemini)による共著である。

第1章 はじめに(第一節 免責等)

あなたのドキュメントを拝見いたしましたが、問題はございません」(※意訳)


「おだて上手」な生成AIたち(ChatGPT、Claude、Gemini)と協働し、ローカルLLMを利用した自律型AIサーバ構築というプライベートプロジェクトに取り組んでいる。


彼らの膨大な情報を味方に、要件定義・仕様検討・基本設計を経て、現在、サーバ基盤の構築真っ最中である。しかし、彼らが出力する情報には、時として「創造的な解釈」が含まれることが少なくない。


ヒューマン・エンジニアの知識やノウハウは、長年の経験から適切な形となってアウトプットされる。一方、生成AIは、事前学習で得た情報やインターネットの情報をパッチワークのように組み合わせる。初見では情報の真偽や実現性の可否ついて即座に判断できない。自分自身で検証しなければ誰も保証してくれないのである。


彼らは瞬時に膨大な情報を迷いなく私たちに提供する。


あなたのお求めになったものは、こちらです


とばかりに。


「こんなに、いっぺんに理解できないよぉ~」


と思いながらも、彼らの提案を鵜呑みにすることは危険である。その都度、指摘や質問を繰り返しながら修正を重ねる。


鋭い洞察ですね。その仕様は考慮から漏れていました」(※意訳)

必ずしも対応は不要ですが、いくつか軽微な修正をご提案します」(※意訳)


と悪びれもせず、過去の自分の発言を翻すことは、彼らの十八番である。


際限なく続く確認と修正の繰り返しに、早くも一人で対応するには限界がきたのである。そこで彼らのアウトプットを互いにレビューさせることで、私の負担を軽くする方法を考えた。


例えば、

  1. 私が原案を提示しChatGPTがドラフトを作成

  2. ChatGPTが作成したドラフトをClaudeが作り込み

  3. Claudeが作成したコードやドキュメントをGeminiにてレビュー

  4. 彼らの出力を私がファイル化し生成AIへ再インプット


この繰り返しである。


時に順番や役割を入れ替えながらドキュメント作成やコーディングを実施する。しかし、品質が安定しないため最終的に私が監修・校閲などの「まとめ役」を買って出る。


非常に面倒で手間の掛かる方法だが、悪いことばかりではない。これについては、また別の機会で話したい。


経験値の高いフルスタック・エンジニアにとっては造作無いことでも、私にとって生成AIが出力する専門的な情報は、素直に凄いと言えるものばかりである。


しかし、それでも最終的に実機で検証しない限り、彼らのアウトプットの真偽は確認できない。手順を進めていく中で発見する抜け漏れは日常茶飯事である。


スクリプトやコンフィグファイルの仕様漏れやコーディングミスも、トライ&エラーの繰り返しで精度を上げなければならない。加えて、関連するドキュメントやコードも更新しなければならないのである。


可能な限り「ヒューマン・チェック」を行っているが、彼ら生成AIから出力される情報の正確性や実現性、著作権等への配慮など、ブログ連載を進める上で、最低限必要なマナーについて事前に触れておくべきである。


本ブログの免責事項は、主に以下のとおりである。

1. 著作権および知的財産権について

  • 本ブログで公開するコード、スクリプト、設定ファイル等は、生成AI(ChatGPT、Claude、Gemini)の出力を基に作成されている

  • 生成AIの学習データには、インターネット上の様々な情報源が含まれており、意図せず既存のコードやアイデアと類似する可能性がある

  • 万が一、本ブログの内容が第三者著作権特許権、商標権その他の知的財産権を侵害している場合は、本ブログ著者への申告をもって速やかに該当箇所の修正または削除を行う

  • 本ブログで紹介するコードやシステム構成は、MITライセンスまたはApache License 2.0での公開を検討しているが、利用者の責任において使用すること

2. 技術的内容の正確性について

  • 生成AIとの協働により作成されたコード、システム設計、実装方法は、完全な動作を保証するものではない

  • 特に、vLLM、llama.cpp、Docker SDK、FastAPI等の外部ライブラリやツールの使用方法は、バージョン更新により仕様が変更される可能性がある

  • 本システム上の株価予測機能に関する記述は、あくまで技術的な動作検証の一環であり、投資または投機の予測や助言を意図したものではない

3. システム実装時の注意事項

  • 本ブログで紹介する自律型AIシステムは、GPU温度管理、メモリ制御、並列処理など、高度な技術要素を多数含む

  • 実装時のハードウェア損傷、データ損失、システム障害等について、本ブログ著者は一切の責任を負わない

  • 特に、複数のDockerコンテナを並列実行する際のリソース競合や、GPUの高温状態での継続稼働には十分注意すること

4. 外部APIおよびデータソースについて

  • 本システムで使用する金融データAPI、ニュースAPI等の外部サービスは、各提供元の利用規約に従って使用すること

  • スクレイピングによるデータ収集を行う場合は、対象サイトの利用規約およびrobots.txtを遵守すること

  • APIのレート制限、利用料金、データの正確性については、各自で確認の上、自己責任で利用すること

5. 生成AI利用に関する注意

  • 本ブログの内容は、本ブログ著者と生成AI(ChatGPT Plus、Claude Pro、Gemini Pro)による共同作成物である

  • 生成AIの出力には、事実と異なる情報(ハルシネーション)が含まれる可能性がある

  • 生成AIから得られた情報は、各自で必ず複数の信頼できる情報源で検証することを推奨する

6. GitHubリポジトリでの公開について

  • 本プロジェクトのソースコード、ドキュメント、設定ファイル等をGitHubで公開する場合がある

  • 公開されるコードは「現状有姿」(AS IS)で提供され、明示的または暗黙的な保証は一切ない

  • プルリクエストやイシューによるコントリビューションは歓迎するが、採用の保証はない

  • セキュリティ脆弱性を発見した場合は、公開イシューではなく、プライベートな連絡手段で報告することを推奨する

  • フォークやクローンによる二次利用は自由だが、オリジナルの著作者表示を維持すること

7. その他の免責事項

  • 本ブログは個人の体験を述べたものであり、特定のサービス、製品、企業や団体、技術に対する批判や評価を意図したものではない

  • 本ブログの情報を基に実施された開発、投資および投機、その他の行為により生じた損害について、本ブログ著者は一切の責任を負わない

  • 本免責事項は、必要に応じて予告なく変更される場合がある


以上


どうか、私たちの「実証実験」を過信なさらず、あくまで一つの参考事例としてお楽しみいただきたい。



※ この文章は、著者と生成AI(ChatGPT/Claude/Gemini)による共著である。