2026-06-07

【自作PC】余ったパーツを再利用！Geminiと二人三脚で組む、Ubuntu環境の実用サブマシン構築記

1. 導入：アップグレードで余ったパーツで新しいPC作成

メインPCのCPUやGPUを新しくした際、手元に残る「数世代前のパーツたち」。そのまま眠らせておくのはもったいない！ということで、これらのパーツを再利用（リユース）して、新しくサブPCを1台構築。

今回のマシンは、Linux（Ubuntu）環境での開発やちょっとした実験用。

2. 構成（スペック一覧）

「手持ちのパーツ」を活かしつつ、足りない土台部分（マザーボード、電源、ケース）を新調する構成。

【再利用パーツ（手持ち）】
- CPU: AMD Ryzen 5 5600G
- GPU: MSI製 GeForce GTX 1660 SUPER
- メモリ: DDR4 16GB
- ストレージ: M.2 SSD 256GB
【新規購入パーツ】
- マザーボード: （≒10,000円, micro-ATX）
- 電源: （≒5,000円, 650W）
- PCケース: （≒5,000円）

3. 組み立ての相棒は「AI（Gemini）」

今回の自作で面白かったのが、「Geminiと対話しながら組み立てを進めた」点。

説明書を見ても「あれ？これどうつけるんだ？」と迷うポイントが時々あります。今回迷ったのが、M.2 SSDの取り付け部分。手持ちのパーツとマザーボードの形状が少し変わった形をしており、一瞬手が止まりました。

そこで、スマホでその部分の写真をパシャリ。そのままGeminiに見せて「これ、どうやって固定すればいい？」と相談してみました。 AIに画像を見せながら「ここはこうだよ」とリアルタイムにアドバイスをもらう感覚は、まるで頼りになるギークな友人が横にいてくれるかのよう。大きなトラブルもなく、スムーズにハードウェアを組み上げることができました。裏配線もすっきりとまとまり、エアフロー抜群の美しいビルドに仕上がっています。

4. OSインストール：Ubuntu 22.04 LTSで開発環境を構築

OSのインストールは手元にあったインストール用のUSBメモリを使い、Ubuntu 22.04 LTSを導入しました。

Ryzen 5 5600GとGTX 1660 SUPERの組み合わせは安定して動作。これからこのマシンを使って、Pythonでの開発や、様々なツールを試していく。

2026-05-08

AI×FreeCAD自動設計の進化：MCPによるツール連携

AI×FreeCAD自動設計の進化

〜「コードを書かせる」から「手足を与える」へ〜

1. 以前のアプローチ：コード直接生成型（生成AI 1.0）

以前のコードでは、Geminiに直接FreeCAD用のPythonコードを「書かせて」いました。

仕組み: システムプロンプトで厳格に「コードのみを出力せよ」「AppやGuiを直接使え」と教育し、出力された文字列をそのまま exec() へ流し込む方式。
課題:
- 構文エラーとの戦い: AIが「つい」Markdownの枠を付けてしまったり、存在しないAPIを捏造（ハルシネーション）したりすると即座にエラー。
- リトライの限界: エラーが出た際にその内容をAIに突き返して「修正して」とお願いするループが必要で、効率が悪かった。
- 職人芸: AIに正しく書かせるために、人間側が「呪文（プロンプト）」を磨き続ける必要があった。

2. MCPによるツール連携

現在の構成は、AIにコードを書かせるのではなく、AIが「あなたが定義したツール（bridge.py）」を選択して実行する方式です。

仕組み: bridge.py が「手足」となり、create_box や make_cut といった確実な関数を提供。AI（Gemini）は設計図を見て、どのタイミングでどのツールを使うべきか「推論」に専念する。
進化のポイント:
- 確実性: AIが生成するのは「コード」ではなく「ツールの名前と引数（JSON形式）」。構文エラーの概念がほぼ消えた。
- 専門知の分離: 「どう描くか（低レイヤー）」は人間が bridge.py で定義し、「何を描くか（高レイヤー）」はAIが担当。役割分担が明確になった。
- 自律性: マルチステップ・ループにより、AIが「次は穴あけだ」と自分で状況を判断して連続実行できる。

3. 比較表：旧・新アプローチの違い

比較項目	以前（コード生成）	現在（MCP + ツール実行）
AIの役割	コードを書く	指揮者（ツールを選ぶ）
出力形式	生のPythonコード（不安定）	構造化された実行命令（確実）
エラーの質	構文エラー、APIの誤用	物理的な配置ミス（推論のミス）
拡張性	プロンプトを増やすしかない	`bridge.py` に関数を追加するだけ
キャリアの活用	通信知識をプロンプトに活かす	通信知識で「神経系（MCP）」を構築する

4. 結論：bridge.pyの「解像度」が設計の質を決める

以前のコードでは、AIがいかに「賢くコードを書くか」に依存していました。しかし、MCP版では「人間がいかに使いやすいツール（bridge.py）を定義するか」に重心が移っています。

【補足】MCP（Model Context Protocol）

MCP（Model Context Protocol） について

1. AIと外部世界を繋ぐ「共通規格」

従来、AIに特定のツール（今回の場合はFreeCAD）を操作させるには、その都度専用の連携プログラムをゼロから組み上げる必要がありました。

MCPは、「AI（知能）」と「外部ツールやデータ（手足・知識）」を繋ぐための標準的なインターフェース規格です。Anthropic社によって提唱されましたが、現在はGoogle Geminiをはじめとする主要なAIモデルでの活用が急速に広がっています。

2. なぜMCPが必要（カプセル化の恩恵）

以前の方式では、GeminiにFreeCADの内部APIを直接教え込み、コードを生成させていました。これは、いわば「脳が直接筋肉の細胞一つひとつに電気信号を送る」ようなもので、非常に不安定でした。

MCPを導入することで、以下のような役割の分離（カプセル化）が実現しました。

MCPサーバ (bridge.py):

「箱を作る」「穴をあける」といった具体的な手順を定義し、AIに対して「私はこれらのツールを持っています（ListTools）」とカタログを提示します。
MCPクライアント (client.py):

AIの思考結果を受け取り、サーバへ実行を命じる司令塔です。
AI（Gemini）:

カタログの中から今の状況に最適なツールを選び、必要なパラメータ（寸法など）を決定する「推論」に専念します。

3. 「翻訳」がいらなくなるメリット

MCPの最大の特徴は、AIがツールの使い方を自律的に理解できる点にあります。

ツールを定義する際に「これはM3のネジ穴をあけるツールです」という説明（メタデータ）を添えるだけで、AIはそれを読み取り、人間が詳細な指示を与えなくても「ネジ穴が必要ならこのツールを使えばいいんだな」と判断できるようになります。

4. まとめ：MCPがもたらした「神経系」の確立

今回のFreeCAD連携において、MCPは単なる通信プロトコルではありませんでした。それは、AIという汎用的な知能が、FreeCADという専門的な肉体を自在に操るための「神経系」そのものを構築したと言えます。

「コードを書かせる」という不安定な段階を脱し、「定義されたツールを使いこなさせる」という一段上のステージへ。MCPの導入は、AIを「チャット相手」から「実務を担うパートナー」へと変えるための、不可欠なステップです。

2026-05-06

LlamaIndexで構築する「専門知識を持つAI」：RAG開発

独自のドキュメントや専門知識をAI（LLM）に学習させずに活用する手法として、**RAG（Retrieval-Augmented Generation：検索拡張生成）**が注目されています。今回は、LlamaIndexを使用したRAG開発についてまとめます。

1. RAGの役割：LLMに「教科書」を渡す

LLM（Geminiなど）は非常に強力ですが、学習データに含まれない最新情報や、特定の非公開ドキュメントについては正確に答えられません。

RAGは、LLMに**「関連する資料（コンテキスト）」**をリアルタイムで渡すことで、この問題を解決します。

LlamaIndexとLLMの役割分担

LlamaIndex（有能な司書）: 膨大な資料から質問に関連する箇所を猛スピードで探し出し、「これに基づいて答えてください」と準備する。
- 「関連する箇所」の具体例:
  1. 意味の近い断片（Node）: 言葉の表面的な一致だけでなく、ベクトル検索によって「意味やニュアンス」が近い文章（例：「ネジの締め方」に対し「ボルトの固定手順」）を抽出します。
  2. メタデータと文脈: ファイル名、見出し、あるいは検索箇所の前後の文章など、回答の根拠として必要な付随情報を含みます。
  3. 数学的な類似度: 数値化されたベクトル同士の距離（コサイン類似度など）が近い上位数件を、信頼できる資料としてピックアップします。
Gemini / LLM（専門家）: 渡された資料を読み込み、内容を理解した上で、以下のプロセスを経てユーザーに分かりやすい回答を構成します。
- 情報の要約と合成: 複数の検索結果にまたがる断片的な情報を整理し、重複を省きながら、一つのまとまった回答として再構築します。
- 構造化と視覚化: 単なるテキストの羅列ではなく、箇条書き、太字、ステップ形式の解説などを用いて、視覚的に理解しやすい形式で出力します。
- 回答トーンの最適化: ユーザーの質問意図に合わせて、初心者向けの丁寧な解説や、専門家向けの簡潔な技術回答など、適切な口調や難易度に調整します。
- 根拠（ソース）の提示: 「どの資料のどの部分を引用したか」を明示することで、情報の透明性と信頼性を確保します。

2. なぜLlamaIndexを使うのか？

単なるベクトル検索を超えた「データ活用のための高度な抽象化」が最大の魅力です。

データの「Node」管理

テキストを単なる文字列ではなく、**Node（ノード）**という単位で管理します。これにより、出典、ページ番号、前後の文章といったメタ情報を保持したまま検索が可能です。

インデックスの永続化

VectorStoreIndex を使用することで、ベクトル化したデータをローカルストレージに保存し、再利用できます。毎回APIを叩いてベクトル化し直す必要がないため、コストと時間を節約できます。

3. RAGの仕組み：ベクトル検索とプロンプト

ベクトル検索のプロセス

質問のベクトル化: ユーザーの質問をEmbeddingモデルで数値（ベクトル）に変換。
類似度計算: 質問ベクトルと、保存済みデータのベクトルを比較（コサイン類似度など）。
抽出: 意味が近い文章の断片（Node）をピックアップ。

プロンプトによる「回答の制限」

RAGは最終的に「検索結果 + ユーザーの質問」を一つのプロンプトとしてLLMに送信します。

この際、**「提供した資料以外の情報は使わないでください」**と指示することで、LLMが元々持っている知識（古い情報や無関係な情報）で答えてしまうのを防ぎます。

4. 実運用における重要課題

セキュリティとプライバシー

APIを使用する場合、データは外部サーバーに送信されます。

Gemini API（無料枠）: 送信データがモデルの学習に利用される可能性があるため、機密情報の扱いに注意。
Vertex AI（Google Cloud）: ビジネス向け。データが学習に利用されないことが規約で保証されています。
ローカルLLM: 完全に情報を外に出したくない場合は、PC内で完結するローカルEmbedding/LLMの構成も可能です。

実装の堅牢性（エラーハンドリング）

大量のデータを処理する場合、以下の実装が不可欠です。

リトライ処理: APIのレートリミット（429エラー）対策。
チェックポイント保存: 処理の途中でデータを保存し、メモリ不足やエラー時に最初からやり直さなくて済むようにする。

5. まとめ

LlamaIndexは、単に検索するツールではなく、**「データをLLMが最も活用しやすい形に整えるエコシステム」**です。

LlamaIndexで正確に探し
Geminiで分かりやすく答える
プロンプトで回答の範囲を制御する

この3つのステップを正しく理解し、セキュリティに配慮した設計を行うことが、実用的なRAG開発の近道となります。

2026-05-05

既存ソフトとのAIエージェント連携：FreeCADとGemini 2.5 Flashの連携で自動設計

AIエージェントとの連携により、私たちの働き方は劇的に変わりつつあります。しかし、多くの現場では依然として「AIに相談し、その回答を人間が手作業でソフトに入力する」というステップが残っています。

今回取り組んだのは、**「AIが直接CADソフトを操作し、3Dモデルを生成する」**という、AIを「アドバイザー」から「オペレーター（実行者）」へと進化させる試みです。

1. 開発の背景：なぜ「AI連携」が必要なのか

従来のAI活用は、チャット画面で完結するものが主流でした。しかし、エンジニアリングの現場では、設計や解析といった「実務」こそが核心です。

既存の専門ソフトウェア（今回の場合はFreeCAD）をAIの「腕」として繋ぐことで、人間の意図を瞬時に形にする**「AIエージェント型ワークフロー」**の構築を目指しました。

2. 技術的ハイライト：AppImageと格闘した構築プロセス

Ubuntu環境のAppImage版FreeCADを外部から制御するため、以下の技術スタックを構築しました。

システム構成：クライアント・サーバー方式

クライアント（VSCode）: Gemini 2.5 Flash APIを使用。AIには「FreeCAD Python開発のエキスパート」という役割（ペルソナ）を付与しました。具体的には、以下のシステム・インストラクションを設定することで、解説やMarkdown装飾を一切省いた「実行可能な生のコードのみ」を出力するよう厳密に定義しています。
実際に設定したシステム・インストラクション:
```
あなたはFreeCAD Python開発のエキスパートです。
重要なルール:
1. 生のPythonコードのみを出力してください。Markdownは使用しないでください。
2. 'import math'（小文字）を使用し、'import Math'は使用しないでください。
3. 'App'と'Gui'が利用可能であることを前提としてください。
4. 常にドキュメントの存在を確認/作成してください: if App.ActiveDocument is None: App.newDocument('AI_Design')
5. プリミティブ作成には 'Part.makeCylinder' や 'Part.makeBox' などを使用してください。
```
これにより、日本語の指示から即座に最適なPythonコードを生成し、TCPソケットで送信する仕組みを構築しました。
サーバー（FreeCADマクロ）: FreeCAD内のPythonサーバーを待機。受信したコードをexec()で実行し、リアルタイムに描画。このコードはFreeCADのユーザーマクロとして登録し、ツールバーからワンクリックで起動できるように構成しました。

3. なぜ「既存ソフト×AI」が最強のソリューションなのか

新しいAI専用システムを導入するのではなく、使い慣れた「古い道具」をAIでアップデートすることには、3つの大きなメリットがあります。

資産の継承: これまで蓄積した設計データやマクロをそのまま活用できる。
高い信頼性: 物理計算や演算といった「正解が必要な部分」は、実績ある実績ある既存ソフトに任せることで品質を担保できる。
教育コストの削減: 全く新しい操作を覚える必要がなく、これまでのスキルに「AIという加速装置」を追加するだけで済む。

4. 結び：技術を再定義する楽しみ

昨今、多種多様なソフトウェアにおいてAI連携が主流となる中、自分が日頃活用しているツールをAI化するためにはどのような策があるか。その問いに対し、FreeCADをベースに具体的な連携手法を検討した今回のプロセスは、最新技術の習得に留まらず、これまでの経験（ドメイン知識）をデジタルの力でどう拡張するかを再定義する重要な試みとなりました。

今回の開発を通じて、単なる自動化の枠を超えて、「AIエージェントに目的を伝え、どのように動かすか」という具体的な活用方法を深く学ぶ貴重な機会となりました。これを足がかりに、さらに実務に即したAIエージェントとの連携方法を探求していきたいと考えています。

実装解説：サーバー側のアーキテクチャ

FreeCAD側で実行するマクロは、「通信（待ち受け）」と「実行（GUI更新）」を分けることが最大のポイントです。これにより、外部からの命令を待ちつつ、FreeCADの画面が固まるのを防いでいます。

import socket, threading, FreeCAD as App
from PySide import QtCore

pending_commands = [] # 命令を溜めるキュー

# 1. 通信担当：バックグラウンドで命令を受信し続ける
def start_server():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.bind(('127.0.0.1', 5000))
    s.listen(1)
    while True:
        conn, _ = s.accept()
        pending_commands.append(conn.recv(10240).decode('utf-8'))
        conn.close()

# 2. 実行担当：GUIが動ける隙間に命令を取り出して実行する
def update_gui():
    if pending_commands:
        code = pending_commands.pop(0).replace("import Math", "import math")
        exec(code, globals())
        App.ActiveDocument.recompute()

# タイマーで定期的にチェックし、サーバーを別スレッドで開始
timer = QtCore.QTimer()
timer.timeout.connect(update_gui)
timer.start(100)
threading.Thread(target=start_server, daemon=True).start()

2026-04-19

LangGraphで作る多角的視点討論シミュレーター

AIエージェントで「不毛な議論」を打破する：LangGraphで作る多角的視点討論シミュレーター

はじめに

人間同士の議論では、時に「それは時と場合による」「絶対とは言えない」といった、論点を煙に巻くような反論で話が停滞してしまうことがあります。感情やプライドが邪魔をして、建設的な着地点が見えなくなるのは世の常です。

しかし、AIエージェントに特定の役割（ペルソナ）を背負わせ、論理のレール（グラフ）の上で戦わせたらどうなるでしょうか？

今回は、GoogleのGemini 2.0 FlashとLangGraphを組み合わせ、資本主義と社会主義という相反する視点から社会問題を深掘りする「討論シミュレーター」を開発しました。

プログラムの構成と仕組み

このシステムは、単一のAIに「中立的に答えて」と頼むのではなく、3つの役割を持ったエージェントを定義し、それらを構造的に連携させています。

システム構成図

司会者 (Moderator Intro): 現代の社会問題から適切なテーマを提示します。
資本主義者 (Capitalist): 自由競争や個人のインセンティブ、市場経済の優位性から持論を展開します。
社会主義者 (Socialist): 平等、社会保障、公共の利益、富の再分配の観点から反論します。
人間 (User Input): AI同士の議論を聞いた上で、自身の意見を投じます。
司会者 (Conclusion): 全ての意見を統合し、多角的な視点を尊重した総括を行います。

技術的なポイント：LangGraphによる状態管理

このプログラムの肝は、DebateState という「共有メモリ」にあります。

各エージェントが発言するたびに、メッセージ履歴（messages）が自動的に蓄積され、次のエージェントはその文脈を読み取って発言します。

Python 

class DebateState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], operator.add] # 履歴を自動追加
    topic: str     # 議論のテーマ
    user_input: str # ユーザーの感想

AIに議論させることの真価

1. 感情を排した論理の衝突

AIには「嫌われたくない」という感情がありません。プロンプトで「熱烈な資本主義者」と定義されれば、その立場を最後まで論理的に貫き通します。「絶対とは言えない」といった曖昧な回避を許さない設定にすることで、議論の核心へ最短距離で到達できます。

2. 止揚（アウフヘーベン）の体験

相反する二つの意見をぶつけることで、ユーザーは「正」と「反」の両面を客観的に眺めることができます。最後に司会者がそれらを統合（合意形成）するプロセスは、単なる情報の羅列よりも深い洞察を与えてくれます。

3. 意思決定のツールとしての応用

今回は政治思想をテーマにしましたが、これはビジネスシーンでも応用可能です。

「攻めのマーケター」 vs 「守りの財務」
「実装重視のエンジニア」 vs 「保守性重視のテスター」

このように異なる利害関係者をシミュレートすることで、人間が気づかなかったリスクや可能性を可視化できます。

おわりに

AIを単なる「回答マシン」として使う段階は終わり、これからは「思考のプロセス」を設計する時代です。LangGraphのようなツールを使うことで、私たちは複数の視点を自由に操り、より高度で、より「逃げのない」意思決定を行えるようになるはずです。

「人間だとこじれてしまう議論」こそ、AIに一度預けてみる。そんな未来がもうすぐそこまで来ています。

2026-03-28

AIチャットの限界を「構造」で突破する ―― Difyによるマルチエージェント設計への道程

1. 考察：なぜAIチャットだけでは「爆発的な創造」が起きないのか

現在、多くの人がAIチャットで文章、画像、動画を生成し、その利便性を享受しています。しかし、実務や経営判断の最前線において、このレベルの利用では「爆発的な創造力」にはつながりません。

汎用的なAIチャットは、あくまで「一問一答」の受動的なツールであり、平均的な回答を出すことには長けていますが、再現性や深い洞察を維持することには限界があります。真のイノベーションを生むためには、AIを「便利な道具」から「制御可能な思考プロセス」へと昇華させる必要があります。

2. 「魔法」を「技術」に変えるための三段階

AIのポテンシャルを実務に組み込むため、技術習得において以下のステップを辿ることは一つの必然と言えます。

Step 1: AIチャット（期待と限界の理解）

まずは素のチャットで、何ができ、何ができないかを見極めるフェーズです。ここで「AIは極めて賢いが、自律的なパートナーではない」という構造的な限界を理解することが出発点となります。
Step 2: LangGraph（ロジックの構造化）

次に、Pythonベースのフレームワーク等で「循環（ループ）」や「条件分岐」といった、プログラミング的な制御をAIに持たせる重要性を学びます。しかし、実務現場で即応的にプロンプトを調整し、チームで共有・運用するには、コード記述の壁が厚いという課題も浮き彫りになります。
Step 3: Dify（オーケストレーションの完成）

そして行き着くのが、Difyのようなプラットフォームです。構造化の重要性をGUIで直感的に、かつGitHub公開という透明性を持って実装できる。まさに「ガレージでエンジンを組み上げる」ような感覚で、AIを真の制御下に置くことが可能になります。

3. 視点の転換：AIに「答え」を書かせてはいけない

高度な専門タスクや、新規事業の市場参入戦略のような「正解のない問い」において、AIに単なる「答え（戦略案）」を書かせてはいけません。重要なのは、「どう考えるべきかというプロセス」そのものを設計することです。

事例：新規事業の「市場参入シミュレーション」

例えば、海外でのヘルスケア事業展開を考える際、AIチャットに戦略を尋ねれば、どこにでも書いている「教科書的な市場分析」が返ってきます。しかし、Difyで以下の**マルチエージェント（思考の構造）**を設計すると、結果は一変します。

エージェントA（文化・宗教専門家）： 「現地の家族観や宗教的タブーは何か？」と、数字に現れない障壁を執拗に洗い出す。
エージェントB（冷徹な財務アナリスト）： 「競合の資本力に対し、我が社の撤退基準はどこか？」と、最悪のシナリオを突きつける。
エージェントC（統合ストラテジスト）： AとBの矛盾をぶつけ合い、独自の勝機を導き出す。

AIに「答え」を求めるのをやめ、専門家の視点を戦わせる「型」を与えた瞬間に、人間一人では到達できなかった多角的な洞察――すなわち爆発的な創造力が手に入ります。

4. 結論：AIを「生成」させるな、「思考を設計」せよ

理系の計算であれ、文系の戦略であれ、AIに「答え」というアウトプットを求めると、返ってくるのは常に「平均点」です。

しかし、AIに「専門家の視点」と「議論のプロセス」という構造を設計すれば、そこから生まれるのは再現性のある「未踏の最適解」になります。この「構造化されたマルチエージェント」の連携こそが、AIチャットの限界を突き破る唯一の解なのです。

2026-02-21

録音データ、本当に活用できていますか？：信号処理とWhisperで構築する「お宝」抽出パイプラインの設計思想

1. はじめに：AI時代の「データの洪水」をどう捌くか

ボイスレコーダーで毎日数時間の記録を取っていると、すぐに数テラバイトの音声データが積み上がります。これをすべてWhisperなどのASR（自動音声認識）に投げるのは、計算リソース（GPU時間）の無駄であり、何より「無音区間でのハルシネーション（幻覚）」というAI特有の問題に直面します。

本記事では、「信号処理による特徴量抽出」と「AIによる文字起こし」を組み合わせた、効率的な音声解析パイプラインの構築について解説します。

2. 解析パイプラインのアーキテクチャ

本システムは以下の4つのステージで構成されるパイプラインとして設計しました。

Segmentation: 長尺ファイルを1分単位のチャンクに分割
Audio Profiling: torchaudio を用いた物理量（RMS, Spectral Flatness）の抽出とスコアリング
Heuristic Selection: タイムウィンドウ（30分間隔）内での代表ファイル選出
AI Transcription: 厳選された区間のみを Whisper-medium で推論

3. 実装の肝：信号処理によるフィルタリング

3.1 RMS（音量）とSpectral Flatness（スペクトル平坦度）

単に音量が大きい箇所を探すだけでは、空調の「ゴー」という音や電車の走行音を拾いすぎてしまいます。そこで、**Spectral Flatness（スペクトル平坦度）**を導入しました。

RMS (Root Mean Square): 音のエネルギー。
Spectral Flatness: 音のスペクトルがどれだけ平坦かを示す指標。
- ホワイトノイズに近い音（ザーという音）ほど 1.0 に近づく。
- 声のように特定の周波数にエネルギーが集中する音ほど 0 に近づく。

この2つを組み合わせ、独自の「お宝スコア」を算出します。

# スコア算出ロジックの核
score = rms / (flatness + 1e-5)

この式により、「ノイズが少なく、明瞭な声が入っている区間」をアルゴリズム的にあぶり出します。

3.2 30分間隔の代表選出アルゴリズム

一日全体の流れを把握するため、単純な「上位N個」ではなく、**「時間帯ごとの代表」**を選出します。

pandas の groupby を活用することで、各時間枠内で最も高いスコアを持つファイルを抽出します。

4. Whisper推論の最適化とハルシネーション対策

文字起こしフェーズでは、1分単位のチャンク処理特有の課題を以下の設定で解決しました。

VRAM管理: RTX 3060の12GBを活かし、mediumモデルを採用。
ハルシネーション抑制: 無音やノイズ区間を無理やり文字化させない設定。
- no_speech_threshold=0.6: 無音判定を厳格化。
- condition_on_previous_text=False: チャンク間の文脈依存を切り、ループ現象を防止。

5. 分析を加速させる Reviewer GUI

解析結果のCSVをフロントエンドとして活用するTkinter製のGUIツールを構築しました。

Treeviewによる動的ソート: ファイル名（時間軸）での確認と、スコア順（重要度軸）での確認をトグル可能に。
非同期再生: pygame ミキサーを使い、リストをダブルクリックした瞬間に該当の1分間をロードして再生。

6. 考察：環境音のセマンティック解析

今回面白かったのは、文字起こし結果から「今、電車に乗っている」「オフィスにいる」といったコンテキストの自動推測の可能性が見えたことです。

例えば、電車の通過音がある区間はWhisperがハルシネーションを起こしやすいですが、逆に言えばその信号特性を捉えることで、行動ログとしてのタグ付けが自動化できます。

7. まとめと展望：LLMへの橋渡し

本パイプラインにより、数時間の録音をわずか10分〜15分程度の「代表区間」の確認だけで把握できるようになりました。

今後の展望としては、厳選された音声チャンクを Gemini 1.5 Pro/Flash API に投げ、背景音からの状況推測や、より高精度なマルチモーダル要約を自動生成するステージを追加する予定です。

技術スタック:

Python 3.11
PyTorch / torchaudio
OpenAI Whisper
NVIDIA GeForce RTX 3060 (12GB)