NEGABARO AI
AI/MLの核心コンセプトをまとめた技術百科事典
基礎
ニューラルネットワークとは？層と重みと逆伝播で学ぶ仕組み
ニューロンを模倣したコネクショニスト学習モデル
入力データを複数の層（layer）の重みで変換し、逆伝播（backpropagation）で誤差を減らしていく学習方式
Transformerとは？Self-Attentionで並列に読む仕組み
RNNの逐次処理の限界をどう越えたか
「Attention Is All You Need」 — RNNの逐次処理の限界をSelf-Attentionメカニズムで解決し、入力シーケンス全体を並列処理するアーキテクチャ
AI前処理の難易度 — テキスト、画像、オーディオ、ビデオ、3Dの順に難しくなる
model(input)は1行だが、そのinputを作る前処理は分野ごとに全く違う
AIは全部model(input)→outputだが、inputを作る前処理の難易度が分野ごとに違う。テキスト（トークン化=ルックアップ）が最も簡単で、画像（リサイズ+正規化）、オーディオ（STFT+メル）、ビデオ（フレーム抽出+時間軸）、3D（点群+ボクセル）の順に難しくなる。AI勉強を始めるならテキストから。
テキストAI事前学習モデルカタログ — 3行コードでできる12のこと
感情分析からコード生成まで — HuggingFace pipeline 1行で済むモデルリストと難易度
テキストは前処理がトークン化（ルックアップテーブル）だけでAI入門に最適。HuggingFace pipelineで感情分析、翻訳、要約、質疑応答、テキスト生成、コード生成、NER、類似度比較など12種を3行コードで実行可能。タスク別推薦モデル、サイズ、難易度を整理。
HuggingFace pipeline() — AIモデルのnpmが動く仕組み
Hubに100万以上のモデルが登録され、pipeline()が名前で自動ダウンロードし推論まで行う
HuggingFace HubはAIモデルのnpmだ。誰でもモデルをアップロードでき、pipeline()が名前だけで重み・トークナイザー・設定を自動ダウンロードする。テキスト、オーディオ、画像、ビデオ — タスク名を変えるだけで同一インターフェースで100万以上のモデルを使える。
ラップAIモデルカタログ — 歌詞生成、ライム検出、フロー分析まで
GPT-2ラップファインチューニングモデル + pronouncingライム分析 + 実行可能コード全部
HuggingFaceにラップ歌詞生成モデルが複数ある。GPT-2をラップ歌詞でファインチューニングしたモデルをpipeline()で直接実行でき、pronouncingライブラリでライム検出・音節分析も可能。歌詞生成→ライムチェック→フロー分析まで全部コードでできる。
PyTorch・Hugging Face・Ollamaを同じ棚に並べるな — AIフレームワークは3層だ
何で計算するか・何でモデルを読み込むか・何で速く動かすか
AIフレームワークは、基盤フレームワーク（PyTorch）・モデルライブラリ（HF transformers）・推論エンジン（llama.cpp・Ollama・vLLM）の3層に分かれる。比較は同じ層の中でだけする。Railsからローカルモデルを使うなら、結局Pythonサーバーを別に立てるかONNXで呼ぶことになる。
構造は回路図、重みはつまみの位置 — そしてAttentionの変形はn²を避けるための改造だ
重みが公開されればすぐ使えるのか、GQAはなぜ長い文脈で必須なのか
モデルのファイルは設計図（config）と重みに分かれる。設計図はたいてい公開されていて、モデルの知識はすべて重みにある。各社の違いのうち構造側は主にAttentionの改造で、全トークンが全トークンを見るn²のコストとKV cacheのメモリを減らすためのものだ。
トレーニング
事前学習（Pre-training）とは？LLMが汎用知識を身につける段階
大規模テキストで次トークン予測を繰り返す
インターネット規模のテキストデータで次トークン予測（Next Token Prediction）を繰り返し、言語の文法・事実・推論能力などの汎用知識を習得する過程
ファインチューニングとは？事前学習モデルを特定タスク向けに再学習
汎用モデルを専門家モデルに変える追加学習
Pre-trainedモデルの重みを特定ドメインやタスクのデータで追加学習し、汎用モデルを専門家モデルに変換する過程
RLHFとは？人間の評価でLLMの応答を整える仕組み
人間フィードバックに基づく強化学習
人が「この答えのほうがいい」と選んだ記録で報酬モデルを作り、そのスコアが上がるようにPPOでLLMを直す方法。この記事を読めば3段階それぞれが何をしているかが分かり、自分の案件にSFT・DPO・RLHFのどれが合うかを選べる。
DPOとは？RLHFの報酬モデルとPPOを省くアライメント手法
報酬モデルなしで好みデータから直接学習
「選んだ答え / 捨てた答え」のペアでLLMを直接学習させ、RLHFの報酬モデルとPPOを飛ばす方法。この記事を読めば、DPOの損失が何を押して何を引くのか、βと損失の数字をどう読むか、RLHFの代わりにいつ使っていいかが分かる。
LoRAとは？少ないパラメータで済むファインチューニング
元の重みは固定し、低ランク行列2つだけ足す
元の重みは凍結し、小さな行列2つ（B・A）だけを学習するファインチューニング。7B相当のモデルに実際に付けて数えると、学習パラメータは0.06〜0.6%だった。読めば自分のGPUにFull FT・LoRA・QLoRAのどれが合うか選べる
推論 vs ファインチューニング — 他人のモデルを使うことと自分のモデルを作ることの違い
pipeline()は出前注文、ファインチューニングはレシピを受け取って自分の味に調整すること
推論は他人が訓練したモデルをそのまま使うこと。ファインチューニングはそのモデルを自分のデータで再訓練して自分のモデルを作ること。ゼロから訓練するのではなく、すでによく訓練されたモデルをベースに微調整するだけなので、ノートPCのGPU1つでもできる。感情分析がファインチューニング入門に最適。
世界一シンプルなファインチューニング理解 — 合体ではなく調整だ
66M個の数字を少し変えること。データをモデルに注入するのでも、モデル同士を合体するのでもない
ファインチューニングはデータをモデルに合体することでも、モデル同士を足すことでもない。完成済みモデルの重み（66M個の数字）を自分のデータを見せながら微調整すること。大学卒業生にOJTを施すようなもの — 教科書を読み直すのではなく、既存の知識の上に新しい業務を教えること。
LoRA — 66M個を全部変えず、1M個のアダプターだけ挿す
ファインチューニングの効率的代替 — ベースモデルは固定し、小さい行列2つだけ訓練
ファインチューニングは66M個の数字を全部調整する。LoRAはベースモデルを凍結し、横に小さいアダプター（1M個）だけ訓練する。品質は同等で訓練時間・メモリ・保存容量が大幅に減る。スマホにケースを付けるようなもの — 本体を変えるのではなくケースだけ交換。
RAG — モデルを再訓練せず「参考資料」を添付する方法
検索（Retrieval）+ 生成（Generation）— モデルの重みは変えず外部知識をプロンプトに添付
RAG（Retrieval-Augmented Generation）はモデルの重みを一切変えない。代わりに質問が来たら関連文書を検索してプロンプトに添付してからモデルに渡す。試験にオープンブック参考資料を持ち込むようなもの。ファインチューニングと違い、データが変わったら文書を更新するだけ。
モデルマージ — 本当に2つのモデルを「合体」する唯一の方法
韓国語モデル+コーディングモデル=韓国語でコーディングするモデル？重みの平均で合体
モデルマージはAIで唯一「合体」に該当する技法だ。2つのモデルの重みを平均して1つにする。韓国語モデルとコーディングモデルを合わせると韓国語でコーディングするモデルになるかもしれない。訓練なしで合体するのでGPUも不要。ただし実験的で結果は保証されない。
推論
プロンプトエンジニアリングとは？入力の設計でLLMの出力を導く
モデルの重みは変えず、入力だけで性能を上げる
LLMに最適な入力（プロンプト）を設計して望む出力を誘導する技術。モデルの重みを変えずに入力だけで性能を最大化
RAG（検索拡張生成）とは？検索した文書を添えてLLMに答えさせる
学習データにない最新・専門知識も使える
LLMが回答を生成する前に、関連文書をベクトルDBから検索（Retrieval）してプロンプトに添付し生成（Generation）する方式。学習データにない最新/専門知識も活用可能
Chain-of-Thought（CoT）とは？段階的に考えさせて推論を強くする
数学・論理・コーディングで効くプロンプト技法
LLMに「ステップバイステップで考えよう（Let's think step by step）」と指示し、中間推論過程を明示的に生成させるプロンプティング技法。数学、論理、コーディング等の複雑な問題で性能が大幅向上
Function Callingとは？LLMがJSONで外部ツールを呼ぶ仕組み
関数スキーマを渡す → モデルが引数を選ぶ → 実行結果を返す、の流れ
モデルは関数を実行しない。「この関数をこの引数で」というJSONを出すだけで、実行するのは自分のコードだ。読めば、リクエスト → 呼び出し → 実行 → 結果を返す往復を自分で組めて、構造化出力・MCPとの違いも見分けられる
Jev — 文章を書かないLLM、判断だけを速く
入力はLLMのように受け、出力は分類器のように返す。LLMにif文をやらせていた場所を引き取る
Jevは文章の代わりに、決められた選択肢ごとの確率だけを返すモデルだ。タスクごとの学習がいらない分類器のように使え、確率で「自動確定 / 人が確認 / 回す」を分けるのが肝になる。理由を残す必要がある仕事には向かない。
スケーリング & 最適化
量子化（Quantization）とは？重みを低精度にしてモデルを軽くする
FP32・FP16をINT8・INT4に変えてメモリを節約
FP32（32ビット）やFP16（16ビット）で保存されたモデル重みをINT8（8ビット）またはINT4（4ビット）に変換し、モデルサイズとメモリ使用量を1/2〜1/8に削減する最適化技法
知識蒸留とは？大きなモデルの知識を小さなモデルに移す方法
Teacherの出力分布をStudentが真似て学ぶ
大きなモデル（Teacher）の出力分布（soft label）を小さなモデル（Student）が模倣するよう学習させ、小型モデルが大型モデルの性能に近づく技法
MoEとは？一部の専門家だけ動かして大きなモデルを安く回す仕組み
ルーターがトークンごとに専門家を選ぶ — Mixtral 8x7Bの例
1つの巨大なモデルの代わりに、複数の専門家（Expert）ネットワークの一部のみ活性化して処理する構造。全パラメータは大きいが実際の計算は一部のみ実行
投機的デコーディングとは？小型モデルの下書きで推論を速くする
大型モデルは草案をまとめて検証するだけ
高速な小型モデル（Draft Model）が複数トークンを一度に生成し、低速な大型モデル（Target Model）がまとめて検証/修正して推論速度を2〜3倍向上させる技法
Azure OpenAI Batchがある日すべて500に — 入力ファイル500個の上限と、その400を隠した中間API
削除・期限設定・定期掃除のどれを選ぶか、そして4xxを潰さない書き方
Batch APIの入力ファイルは使い終わっても残る。期限を付けないとリソースあたり500個でアップロードが止まり、その400を中間APIが500に変えると原因は二重に隠れる。この記事を読めば、自分のリソースがいつ止まるかを計算し、アップロード時の指定ひとつで防げる。
マルチモーダル
Vision-Languageモデルとは？画像を見て答えるAIの仕組み
画像エンコーダ（ViT）とLLMの組み合わせ
画像エンコーダ（ViT）と言語モデル（LLM）を組み合わせ、画像を見て説明したり、画像に関する質問に回答するマルチモーダルAI
拡散モデルとは？ノイズを少しずつ消して画像を作る仕組み
ノイズを足す過程を逆向きに学習する
画像に段階的にノイズを追加する過程を逆に学習し、純粋なノイズから始めて段階的にノイズを除去しながら画像を生成する技法
テキスト音声合成（TTS）とは？文字を自然な声に変える技術
LLMと組み合わせて感情・抑揚・多言語まで
テキスト入力を自然で表現力豊かな音声に変換する技術。最近はLLMと組み合わせて感情、抑揚、多言語を自然に処理
エージェント & ツール活用
AIエージェントとは？LLMが計画しツールを使って動く仕組み
計画→ツール呼び出し→観察→次の行動のループ
LLMを「脳」として、計画策定→ツール呼び出し→結果観察→次の行動決定を繰り返し、複雑なタスクを自律的に実行するシステム
MCPとは？AIとツールのN×M連携を1つの規格にまとめる仕組み
AIと外部ツールを接続する標準プロトコル
Anthropicが公開したオープンプロトコルで、AIモデルと外部ツール（DB、ファイル、API）を標準化された方式で接続。USB-Cのように「一つの規格で全てのツール」を接続
評価駆動開発とは？Evalの結果でAIシステムを直していく方法
プロンプト・モデル・RAGの変更を自動評価で測る
プロンプト、モデル、RAGパイプライン等の変更が性能に与える影響を自動化された評価（Eval）で測定し、データに基づいて改善する開発方法論
レビュアーは同じなのに結果が違う — AI実装の品質はレビューの手前で決まる
「作って」の一言でPRまで行くやり方と、設計承認ハーネスを並べてみた
AIにコードを任せるとき、品質の差はレビュアーの性能ではなく、コードを書く前に人が何を承認したか、人が最初に見るPRがすでに一度ふるいにかけられているかで決まる。文言1つなら「作って」で十分。設計の選択肢やDB変更があるならハーネス。
AIに本番DBを見せるとき — 書き込みはプロンプトではなくDB権限で止める
execがあるのに調査用リードレプリカと踏み台を別に作った理由と、PostgreSQLで確かめたこと
AIエージェントへの「読むだけにして」は確率的な約束だ。セッションのread-only設定もSET一行で外れる。この記事を読めば、何が本当に書き込みを拒否するのかがわかり、AI調査用のDB接続をどこまで切り離すか決められる。
エージェントに頼むな、フックで強制しろ — oh-my-openagentのコードを読んで自分のハーネスに持ち帰ったもの
失敗ひとつにフックひとつを付けて57個まで積んだハーネスと、フック同士がぶつかって結局入口をひとつにまとめた話
「編集の前に読み直して」「TODOを残して止まらないで」をプロンプトに書けば、だいたい守られる。だいたいだけ。OpenCodeプラグインのoh-my-openagentは、これをフックのコードで止める。この記事を読めば、どのルールをフックに移すか選べて、Claude CodeのStopフックですぐ真似できる。
安全性 & アラインメント
AIアラインメントとは？AIを人間の意図に沿って動かす研究
Helpful・Harmless・Honestという3つの目標
AIシステムが人間の望む通りに行動することを保証する研究分野。「役に立ち（Helpful）、無害で（Harmless）、正直な（Honest）」システムを目標とする
Constitutional AIとは？原則を与えてAI自身に応答を直させる方法
Anthropicの技法 — RLHFの人手を大きく減らす
Anthropicが開発したアラインメント技法。人間が直接フィードバックする代わりに、AIに「憲法（原則）」を与えて自ら応答を批判・修正させ、RLHFの人的労働を大幅に削減した方法
ハルシネーションとは？AIがもっともらしい嘘をつく理由
次トークン予測という学び方から来る限界
LLMが学習データにない、または事実ではない情報を自信を持って生成する現象。次トークン予測という学習方式の本質的な限界に起因する
音声 & オーディオAI
オーディオトークン化とは？コーデックが音をトークンにする仕組み
EnCodec・SoundStreamとRVQ — 今のTTSがLLMのように動く理由
連続的なオーディオ波形をVQ-VAEベースのコーデック（EnCodec、SoundStream等）で離散トークンシーケンスに変換し、テキストのようにTransformerで生成・理解できるようにする技術
音声モデルの進化
ルールベース → ディープラーニングパイプライン → トークンベース → 統合マルチモーダル
音声合成（TTS）技術の発展史: 第1世代（ルール/連結合成） → 第2世代（統計的パラメトリック） → 第3世代（ディープラーニングメルスペクトログラムパイプライン） → 第4世代（トークンベースLLM方式） → 未来（統合マルチモーダル）
GPT-SoVITSのコードで見る事前学習とファインチューニング
オープンソースの音声合成プロジェクトを読む
GPT-SoVITSオープンソースプロジェクトを通じてPre-training（事前学習）とFine-tuning（微調整）が実際のコードでどう実装されるか分析するケーススタディ
Demucsコード分析 — 1つの曲をボーカル・ドラム・ベース・ギターに分離する方法
Meta/Facebook ResearchのHybrid Transformerソース分離モデル — アーキテクチャ、推論パイプライン、実践活用
DemucsはMeta（Facebook Research）が作ったオープンソース音源分離モデルだ。完成した1曲をボーカル、ドラム、ベース、ギター（other）の4ステムに分離する。現行バージョンhtdemucsは時間ドメインエンコーダー・デコーダーと周波数ドメインTransformerを組み合わせたハイブリッドアーキテクチャだ。
Mel-Band RoFormer Karaokeモデル分析 — リードボーカルだけを抽出する913MBの秘密
RoPE + メルスケール周波数分解 + 階層的時間・周波数Transformer — コードと設定まで
UVRコミュニティのaufr33+viperxが訓練したMel-Band RoFormer Karaokeモデルは913MBのPyTorchチェックポイントだ。リードボーカルのみ分離しバッキングボーカルは伴奏に残すカラオケ専用モデル。60個のメルバンドで周波数を分解し、時間・周波数軸を交互に処理する階層的Transformerが核心。SDR 10.1956。
UVR Mel-Band RoFormer vs Demucs — 音源分離モデル比較分析
カラオケ専用2ステム vs 汎用4ステム — アーキテクチャ、学習データ、性能、実践選択基準
最もよく使われる2つの音源分離モデルの比較。UVR Mel-Band RoFormer Karaokeはリードボーカルのみ分離する913MBカラオケ専用モデル、Demucs htdemucsはボーカル・ドラム・ベース・ギターの4ステムに分離する80MB汎用モデルだ。用途が違う。
音源分離2分ガイド — DemucsとUVR Karaokeをローカルですぐ実行する
実測ベース比較 — インストール、実行、処理時間、出力ファイルまで実際に動かした結果
DemucsとUVR Karaokeをローカルで直接インストールして動かした。Demucs：pip install 1行＋実行1行、モデル80MB、10秒音声を10秒で処理。UVR Karaoke：モデル913MB、同じ音声を43秒で処理。簡単なのはDemucs、カラオケ品質はUVR。
オーディオAIの共通基盤技術 — Demucs、Mel-Band RoFormer、GPT-SoVITSが共有するもの
STFTスペクトログラム、Transformerアテンション、エンコーダー・デコーダー、PyTorch — オーディオAIの共通DNA
音源分離（Demucs、Mel-Band RoFormer）と音声合成（GPT-SoVITS）は目的が違うが基盤技術が同じだ。STFTでオーディオを周波数ドメインに変換し、Transformerで長距離依存性を捉え、エンコーダー・デコーダーで分解/復元する。この共通DNAを理解すればオーディオAI全体が見える。
オーディオAI Hello World — 事前学習モデルで5分でやる7つのプロジェクト
pip install 1行+コード3行で音源分離、音声認識、TTS、ピッチ検出、音楽生成まで
訓練なし、GPUなし、コード3行でオーディオAIを体験できる。音源分離、音声認識、TTS、ピッチ検出、音楽タギング、音分類、音楽生成 — 全部事前学習モデルをダウンロードしてすぐ動かすだけで結果が出る。
input → 事前学習モデル → output — AI推論の本質はこの1行だ
STFTもマスキングも忘れろ — モデルがやることはただ一つ、入力を受けて出力を出すこと
オーディオAIパイプラインでSTFT、マスキング、ISTFTは全部数学だ。ニューラルネットがやることはただ1行 — model(input)でoutputを出す。音源分離、音声認識、TTS、音分類、全部この構造だ。
ボイスクローニングは学習ではなくプロンプトだ — 今どきのTTSは音をトークンにしたLLM
Fish Audio APIのフィールドを読んで分かったこと — 声はモデルidではなく参照音声で渡す
今どきのTTSは音声をコーデックのトークンに変え、LLMと同じように次のトークンを当てる。だから「自分の声で話させる」はモデルを学習し直すことではなく、参照音声をプロンプトの前に置くことだ。Fish Audio APIのフィールド名がそれをそのまま物語っている。
OCR & ドキュメントAI
OCRオープンソースカタログ — 画像からテキストを抽出するすべての方法
TesseractからEasyOCR、PaddleOCR、Surya、TrOCR、Qwen2-VLまで — 難易度・言語・速度比較
OCRは完全にニューラルネットワーク分野だ。画像→model(image)→テキスト。最も簡単なEasyOCR（3行、80言語）からCJK最強PaddleOCR、最新高精度Surya、TransformerベースTrOCR、マルチモーダルLLM（Qwen2-VL）まで整理した。
PDF特化OCR — 複雑なレイアウト・表・数式をMarkdownに変換するツール
Marker、Docling、MinerU、Nougat、olmOCR — PDFをLLMが読める形に
通常のOCRは画像からテキストを抽出するが、PDFはより複雑 — 多段レイアウト、表、数式、コードブロック、ヘッダー/フッター。PDF特化ツールはこの構造を理解しMarkdown/JSONに変換する。RAGパイプラインの最初のステップとして必須。
契約書・法律文書向けのOCR — 条項の抽出、当事者の識別、構造化まで
Legal-BERT・CUAD・LayoutLMv3で契約書を構造化し、APIとローカルをどこで分けるかまで
契約書OCRの本題は、文字を抜くことより、抜いた文章から条項・当事者・期限を取り出すことだ。OCR→フィールド抽出→条項分類は定型作業なので小さなモデルやローカルで足り、「不利な条項を探す」ような開かれた解釈だけを大型LLMのAPIに任せる。APIかローカルかは、性能よりも持ち出せるか・定型か・件数で決まる。
日本語特化OCR — 漫画、縦書き、ふりがな、古文書まで
manga-ocr、Sarashina2.2-OCR、PaddleOCR、KuroNet — 日本語OCRのすべての選択肢
日本語OCRが難しい理由：縦書き、ふりがな、ひらがな・カタカナ・漢字混在、漫画特有のフォント。manga-ocr（漫画専用）、Sarashina2.2-OCR（日本語文書最高精度）、PaddleOCR（汎用CJK）、KuroNet（古文書/くずし字） — 用途別推薦。
OCRファインチューニング入門 — 日本語不動産契約書を読む自分のモデル作り
TrOCR + Trainer.train() — 感情分析ファインチューニングと全く同じパターン
OCRファインチューニングは感情分析ファインチューニングと構造が同じ。inputがテキストから画像に変わっただけで、Trainer.train()でモデルの重みを調整するのは同一。TrOCR（ViTエンコーダー+テキストデコーダー）が最も簡単 — HuggingFace標準インターフェースそのまま。
OCR APIカタログ — モデル管理なしAPI 1行でテキスト抽出
Google Vision、Azure Document Intelligence、AWS Textract、Clova OCR — 価格・精度・コード比較
モデルをインストール・管理せずAPI呼び出しだけでOCRできる。Google Cloud Vision（精度最高）、Azure Document Intelligence（契約書・レシート特化）、AWS Textract（表構造化に強い）、Naver Clova OCR（韓国語最強） — コード例と価格を比較した。
日本語契約書OCRベンチマーク — API vs オープンソース、どちらが良いか
Google Vision、Azure、PaddleOCR、Sarashina2.2 — 日本語契約書で精度・速度・価格比較
日本語不動産契約書を基準にAPI（Google Vision、Azure）とオープンソース（PaddleOCR、Sarashina2.2-OCR、manga-ocr）の性能を比較する。精度：Google Vision≈Sarashina2.2 > PaddleOCR > Azure > EasyOCR。コスト：オープンソース0円 vs API ページ課金。
OCR総合比較 — API vs オープンソース vs ファインチューニング、何を使うべきか
3つのアプローチの精度・コスト・セキュリティ・難易度・保守を1枚で比較
OCRを実装する3つの方法：API呼び出し（Google Vision等）、オープンソースセルフホスティング（EasyOCR、PaddleOCR等）、ファインチューニング（TrOCR、manga-ocr）。精度・コスト・セキュリティ・難易度・保守の5軸で比較すると状況により最適な選択が変わる。
Azure Document Intelligence専用モデル全整理 — レシートから契約書まで15モデル
prebuilt-read、prebuilt-receipt、prebuilt-contract、prebuilt-invoice — モデル名を変えるだけで構造化データが出る
Azure Document Intelligenceは単なるOCRではない。文書タイプ別専用モデルが15以上ある。レシートを入れると店名・日付・金額が、名刺を入れると名前・肩書・電話番号が、契約書を入れると当事者・管轄・条項が構造化JSONで出る。モデル名を変えるだけ。
文書構造化抽出API比較 — Azure、Google、AWSそれぞれ何を提供するか
Azure prebuilt-contractのような「文書を理解するAPI」はGoogleとAWSにもある？
Azureのprebuilt-contractのように「文書タイプ別にフィールドを構造化抽出するAPI」はGoogle（Document AI）とAWS（Textract）にもある。ただし対応文書タイプ、言語、価格が全部違う。Azureは専用モデルが最も多く、Googleはカスタムプロセッサが強く、AWSは表抽出に特化。
評価 & 検証
AIモデル評価入門 — 自分のモデルが良いかどうやって分かる？
正解率、BLEU、CER、SDR — タスクごとに異なる評価指標と「なぜこれを使うのか」
モデルを訓練したら評価が必要。だがタスクごとに評価方法が違う。分類は正解率、生成はBLEU、OCRはCER、音源分離はSDR。全部1つの数字に帰結 — 高いほど良いか、低いほど良いか。
タスク別評価チートシート — どの指標を使うべきか一目で
分類→Accuracy/F1、生成→BLEU/ROUGE、OCR→CER/WER、分離→SDR — コード付き
タスクによって使う評価指標が違う。このチートシートで自分のタスクに合う指標を選び3行コードですぐ測定できる。
AI評価ツールカタログ — evaluate、lm-eval-harness、RAGAS、DeepEval
単一指標測定からLLMベンチマーク、RAG評価、自動テストパイプラインまで
単純な指標測定（evaluate）からLLMベンチマーク（lm-eval-harness）、RAGパイプライン評価（RAGAS）、AIアプリテスト（DeepEval）まで — 評価ツールも用途別に違う。
ローカル実行
ローカルLLMツールカタログ — 自分のMac/PCで動かすAI
Ollama、llama.cpp、LM StudioからvLLMまで — 用途別整理
API費用なし、データ漏洩の心配なし、オフラインでも使える。2026年基準でローカルLLM生態系はすでに実用レベル。ツールが多すぎて何を使うかが問題なくらい。
Chrome内蔵LLM（Prompt API）はタダのAPIではない
訪問者のGPUで動く、結果を信用できない計算 — だから補助にだけ使う
ChromeのLanguageModel APIはキーもサーバーもなしでLLMを呼べるが、コストは訪問者の端末に移っただけで、結果はクライアント側でいくらでも書き換えられる。「ごまかされても誰も損しない場所」にだけ使う。
ONNXはモデルではなく梱包規格だ — XenovaはBERTを作ったわけではない
誰が学習させたかと、どの箱に詰めて配るかは別の話
Hugging Faceのリポジトリ名には、モデルを作った人と梱包した人が混ざっている。ONNXは計算の順番と重みを1つのファイルに入れる規格で、Xenovaは学習済みの重みをブラウザ向けに詰め直しただけだ。ONNX版のないモデルはtransformers.jsでそのままは使えない。
顔・アバター・映像AI
話すAIアバターはひとつのモデルではない — STT・LLM・TTSの後ろに顔を付けたパイプラインで、敵は遅延の合計
顔の品質より先に見るもの — 4段階の遅延と、重ねて縮めるストリーミング
話すAIアバターは、STT→LLM→TTSと続く音声エージェントの後ろに顔の生成器を付けたものだ。だから体感品質を決めるのは顔のモデルより4段階の遅延の合計になる。段階ごとに測り、ストリーミングで重ね、割り込みを処理する順に詰めていく。
AIアバターSDKは「どこまで切り離せるか」で選ぶ — Anamの3モードと、切り離すほど増える責任
full・custom_llm・passthroughを組んで引っかかったこと — 400エラー、PCM形式、そしてAPIキーはサーバーに
AIアバターサービスは顔の品質より「どの段階からこちらで持てるか」で選ぶ。Anamにはfull・custom_llm・passthroughの3モードがあり、切り離すほど割り込み処理や音声形式合わせがこちら側に来る。APIキーはサーバーに置き、ブラウザにはセッショントークンだけを渡す。
FaceFusionは手法ではなく部品の組み立て機だ — 顔を変える技術の4系統マップ
顔交換・ID条件付き生成・顔の再演・動画生成 — 系統が違えば比較の対象にならない
顔を変えるAIは、顔交換・ID条件付き生成・顔の再演・動画生成による置き換えの4系統で、系統が違えば比べる対象ではない。FaceFusionは顔交換系統のツールで、検出・交換・補正のモデルを差し替える器だ。部品の多くはInsightFace由来で、モデルのライセンスは非商用研究用に限られる。
顔交換で髪が変わらないのは性能ではなくマスクの範囲のせい — 複数のモデルがリレーするパイプライン
FaceFusionを分解してみたら — 髪は最初から対象外で、ちらつきは「別人」判定だった
顔交換は、検出・ランドマーク・位置合わせ・身元抽出・交換・マスク・補正を複数のモデルが受け渡すパイプラインだ。交換モデルは位置合わせした顔の切り抜きの内側しか描かず、マスクも顔だけを切り抜いて貼るので、どのモデルを使っても髪は変わらない。ちらつきはreferenceモードの「別人」判定が原因で、oneモードにしたら消えた。
MVのワンシーンに自分の顔を入れる — みんながやる方法は3つ、でも解いている問題が違う
FaceFusion・Runway Aleph・Nano Banana Pro + Veoを実際に回した記録 — ひとつは課金の段階で止まった
有名MVのシーンに自分の顔を入れた動画は、たいてい顔だけを替える方式（FaceFusionなど）だ。元の演技や照明はそのままだが、髪は元のものが残る。人物まるごと替えるならRunway Alephのような動画置き換えを、元と違ってもいいなら最初のフレームを編集して動画を新しく作る方式を使う。生成系APIは有名人フィルターに引っかかることがある。
AIタグは「何が写っているか」ではなく「編集でどう使うか」で分ける — 写真・動画4,341件に12軸
家族の動画を作っていて素材選びで詰まり、タグの体系を作り直した — そして半分は目で直した
編集で必要になる問いは「何が写っているか」より「オープニングに使える広いカットはあるか」「字幕を載せる余白はあるか」だ。そこでタグを構図・余白・品質・用途など12軸の `軸:値` に分け、すべてmacOSのローカルで付けた。タグごとに14枚ずつ目で確かめると、最初のルールのまま使えるものは多くなかった。