[{"content":"中古サーバーやエンタープライズ SSD を見ていたり、ワークステーション、NAS、ストレージノードに U.2 NVMe ドライブを入れようとすると、すぐに P5510、P5620、PM9A3、SN640、7450 PRO、CD8 といった型番に出会います。\nこうした型番は、番号だけ見ても直感的ではありません。そのドライブが高性能寄りなのか、高耐久寄りなのか、大容量寄りなのか、読み込み最適化なのか、混合負荷向けなのかを、すぐに判断するのは意外と難しいです。この記事では、よく見かける U.2 シリーズをメーカーごとに整理し、おおまかな立ち位置をつかみやすくします。\n先に一つ前提を置くと、同じシリーズでも容量、ファームウェア、インターフェース世代、耐久度によって複数のサブモデルがあります。ここでの目的は SKU ごとの完全なスペック表ではなく、シリーズごとの役割を理解しやすくすることです。\n01 まず U.2 ドライブをどう分けて考えるか\rエンタープライズ向け U.2 SSD は、おおまかに次のように考えると分かりやすいです。\n汎用型：多くのサーバーや仮想化環境に向き、読み書きのバランスがよい。 読み込み最適化型：読み込みが多く書き込みが少ないデータベース、オブジェクトストレージ、配信、キャッシュ層に向く。 混合負荷型：データベース、ログ、仮想化のように書き込みも無視できない環境に向く。 高耐久型：書き込み量が大きく、低遅延も重視される環境に向く。 大容量 QLC 型：書き込み性能より TB 単価と容量密度を重視する場面に向く。 個人や小規模チームでよくある失敗は、「性能が足りない」ことよりも「用途に合わないクラスを選んでしまう」ことです。たとえば大容量 QLC を重い書き込みに使ったり、高耐久 Optane を単なる保管用途に使ったりすると、あまりうまくいきません。\n02 Solidigm / Intel 系列\rSolidigm は Intel の NAND SSD 事業を引き継いでいるため、この系統は一緒に理解されることが多いです。\nD7-P5510 / P5620\rこの二つは、典型的な PCIe 4.0 世代のデータセンター向け NVMe シリーズで、汎用サーバー、仮想化基盤、企業ストレージノードでよく見かけます。\nD7-P5510 は比較的汎用型かつ読み込み寄り。 P5620 はより混合負荷寄りで、耐久性が高い側として見られることが多いです。 「多くの企業用途で無難に使える U.2 ドライブ」が欲しいなら、このあたりはかなり堅実です。どれか一つの指標が極端に尖っているというより、全体のバランス、安定性、市場流通量の多さが魅力です。\nD5-P5316\rD5-P5316 は、大容量 QLC 路線の代表格として分かりやすいシリーズです。\n魅力は極端な書き込み性能ではなく、容量密度と TB 単価にあります。オブジェクトストレージ、コールド寄りのデータ、大規模な読み込み中心のデータセット、あるいはラックあたり容量をできるだけ積みたい場面では非常に魅力があります。\n一方で限界もはっきりしています。高い書き込み圧力、継続的なランダム書き込み、長期間の重い再書き込みには向きません。要するに、高密度容量ドライブであって、高耐久性能ドライブではありません。\nOptane DC P4800X\rP4800X はまったく別系統の製品です。通常の NAND ではなく、Intel Optane / 3D XPoint 系です。\nこのクラスは次のような特徴で知られています。\n非常に低いレイテンシ 小さなランダムアクセスで非常に強い 書き込み耐久性が非常に高い 高頻度のログ、メタデータ、低遅延データベース、キャッシュ層、非常に重い書き込み圧力のあるシステムでは、Optane は通常の NAND SSD とはまったく違う体感になります。その代わり、容量は小さめで価格も高く、今では汎用大容量ドライブというより、特定用途向けの特別な一枚という印象です。\n03 Samsung 系列\rSamsung のエンタープライズ NVMe は、サーバー市場や OEM 市場でもよく見かけます。特にブランドサーバーやクラウド基盤では存在感があります。\nPM9A3\rPM9A3 はよく見かける PCIe 4.0 世代のエンタープライズシリーズで、比較的主流の立ち位置です。P5510 のようなクラスと並べて考えられることが多いです。\n向いているのは次のような用途です。\n汎用サーバー 仮想化ホスト 読み書きが比較的バランスした企業アプリケーション 世代が古すぎず、性能も十分で、市場でも比較的見つけやすい企業向け U.2 ドライブを探しているなら、PM9A3 は有力候補になりやすいです。\n983 DCT\r983 DCT はもう少し古い世代ですが、前世代の企業プラットフォームで広く使われていたため、今でも印象に残っている人が多いシリーズです。\n成熟していて流通量が多く、価格も下がりやすいため、予算重視で、なおかつあまりマイナーな型番には触れたくない場合に向いています。今見ると「信頼できる古参」という印象で、最新世代を狙うときの第一候補というよりは、堅実な実用品です。\nPM1733 / PM1735\rPM1733、PM1735 は、Samsung の高性能エンタープライズ NVMe を代表する系列です。\nこのクラスは一般に次のようなイメージで見られます。\nシーケンシャル性能が強い より高性能なデータセンター向け 高帯域や高 IOPS を必要とする用途に向く ホストが PCIe 4.0 世代で、データベース、仮想化、計算ノード、高スループットストレージを意識しているなら、PM1733/PM1735 はエントリー向けや古い企業ドライブより魅力的に見えやすいです。\n04 Western Digital / HGST 系列\rWestern Digital / HGST 系の企業ドライブもストレージ分野では非常によく見かけます。特に Ultrastar 系列は定番です。\nUltrastar SN640\rSN640 は読み込み最適化型 NVMe SSD として理解されることが多いです。\n向いているのは次のような用途です。\nコンテンツ配信 読み込み中心のクラウドストレージ ブート用やイメージ保存用 読み込みが多いデータベースのレプリカ このクラスの魅力は、容量、消費電力、読み込み中心用途での全体バランスにあります。読み込み中心のワークロードなら、より高耐久な混合負荷向けドライブよりも経済的なことが多いです。\nUltrastar SN840\rSN840 は、より高性能で上位のデータセンター向け NVMe として理解されることが多いです。\nSN640 が読み込み最適化寄りだとすると、SN840 はより高性能な企業用途向けで、重めの業務アプリケーション、仮想化、データ基盤に向くイメージです。より強いプラットフォーム能力を求める人には魅力がありますが、価格や入手性はやや厳しいこともあります。\n05 Micron 系列\rMicron の企業向け SSD も、ここ数年でサーバー市場にかなり浸透しています。型番の整理が比較的分かりやすい印象があります。\n7450 PRO / MAX\r7450 系列は分かりやすい例で、名前の時点で役割が分かれています。\n7450 PRO：主流の企業用途向けで、汎用または読み込み寄りに向く。 7450 MAX：高耐久で、より重い書き込み用途に向く。 この分け方はかなり直感的です。汎用サーバー、仮想化、アプリケーション基盤なら PRO で十分なことが多く、データベース、ログ、継続的な書き込みが多い環境なら MAX のほうが合っています。\n9400 系列\r9400 系列は、より新しく強いエンタープライズ NVMe の層として見られます。高スループット、高 IOPS、より重いサーバー負荷を想定した位置づけです。\n新しいプラットフォーム、強い性能、重い業務負荷を狙うなら 9400 は 7450 より魅力的に映りやすいです。一方で、普通のストレージノードやホームラボ用途では、必ずしも最もコスト効率のよい選択ではありません。\n06 Kioxia 系列\rKioxia も企業向け SSD では非常によく見かけるメーカーです。OEM サーバー、ブランド機、企業調達ルートでもよく登場します。\nCD6\rCD6 は典型的な PCIe 4.0 世代のデータセンター向け NVMe シリーズで、全体としては主流の企業用途向けです。\n向いているのは次のような用途です。\n汎用サーバー クラウドノード 企業アプリケーションの配備 バランスのよい混合負荷 特に尖ってはいないが、企業環境で安定して使いやすいシリーズを探しているなら、CD6 は候補に入りやすいです。\nCD8\rCD8 は、より新しく、性能とプラットフォーム仕様が一段上がった系列として見られることが多いです。\nより新しい基盤、高い性能期待、より現代的なデータセンター構成を重視するなら、CD8 は CD6 より注目しやすいシリーズです。その代わり、価格も高くなりやすい傾向があります。\n07 選ぶときの簡単な見方\rまずざっくり候補を絞りたいなら、次のように考えると分かりやすいです。\n汎用で無難：P5510、PM9A3、CD6 混合負荷や高耐久：P5620、7450 MAX 大容量で TB 単価重視：D5-P5316 超低遅延・超高耐久：Optane P4800X より高性能な新しめのデータセンター向け：PM1733/PM1735、SN840、9400、CD8 成熟した旧世代で価格重視：983 DCT これは厳密なスペック表ではなく、最初に全体像をつかむための実用的な地図として使うのがよいです。\n08 短いアドバイス\rNAS、実験環境、仮想化ホスト向けに U.2 企業ドライブを買うなら、最初に確認したいのは次の三点です。\nバックプレーン、変換ケーブル、HBA、マザーボードが本当に U.2 NVMe をサポートしているか。 自分の用途が容量重視なのか、耐久重視なのか、低遅延重視なのか。 企業 OEM 向けの特殊ファームウェア品ではなく、後で互換性や更新に困らないか。 型番はもちろん重要ですが、インターフェース互換性、冷却、電源、プラットフォーム対応も同じくらい重要です。まずシリーズの立ち位置を理解してから容量や価格を選ぶほうが、型番だけを見て手探りするよりずっと効率的です。\n","date":"2026-04-15T22:19:10+08:00","permalink":"https://www.knightli.com/ja/2026/04/15/common-u2-enterprise-ssd-series/","title":"代表的な U.2 エンタープライズ SSD 系列整理"},{"content":"RAGFlow は infiniflow によるオープンソースの RAG（Retrieval-Augmented Generation）エンジンです。単なる「ドキュメントをアップロードして質問する」ための薄いナレッジベース外殻ではなく、ドキュメント解析、チャンク分割、検索、リランキング、引用の追跡、モデル設定、Agent 機能、API 統合までを一つのワークフローにまとめることを目指しています。\n企業向けナレッジベース、ドキュメント Q\u0026amp;A、サポートアシスタント、社内情報検索、あるいは LLM により信頼できるコンテキスト層を持たせたい場合、RAGFlow は重点的に見る価値のあるオープンソース案の一つです。\n01 RAGFlow は何を解決するのか\r一般的な RAG システムがぶつかりやすい問題は主に三つあります。\nドキュメント解析の品質が安定しない。特に PDF、スキャン文書、表、画像、複雑なレイアウトで起きやすい。 チャンク分割戦略が見えにくく、検索ヒットはしていても実際の文脈が不完全になりやすい。 回答に信頼できる引用がなく、利用者が出典を確認しにくい。 RAGFlow はまさにこの部分に力を入れています。README では Deep document understanding、テンプレート化されたチャンク分割、チャンクの可視化、引用のグラウンディング、多経路検索とリランキングが強調されています。つまり、単にベクトルデータベースとチャット UI をつなぐのではなく、「高品質な入力が高品質な回答につながる」ことを重視しているということです。\n02 主な機能\r1. 高度なドキュメント理解\rRAGFlow は複雑な非構造化データから知識を抽出できます。README に挙げられている形式には Word、PPT、Excel、TXT、画像、スキャン文書、構造化データ、Web ページなどがあります。\nこれは企業ナレッジベースにとって非常に重要です。現実の資料はきれいな Markdown ではなく、契約書、レポート、表、スキャン PDF、製品マニュアル、スクリーンショット、Web ページが混在していることが多いからです。解析品質が低いと、その後のベクトル検索も LLM の回答も弱くなります。\n2. テンプレート化されたチャンク分割\rRAGFlow はテンプレートベースの chunking を提供します。ここでの価値は、チャンク分割がブラックボックスではなく、文書タイプに応じてより適切な戦略を選べることです。\nたとえば通常の記事、論文、表、Q\u0026amp;A 文書、画像説明、契約条項では、チャンクの粒度や境界の考え方が異なります。テンプレート化された分割により、「文が途中で切れる」「表の文脈が失われる」「見出しと本文が分かれてしまう」といった問題を減らせます。\n3. 追跡可能な引用\rRAGFlow は grounded citations を重視しています。つまり、回答がどのソース断片に基づくのかを追えるということです。さらにチャンクの可視化もあり、解析結果やチャンク分割結果を人が確認して調整しやすくなっています。\nこれは本番環境では特に重要です。企業内 Q\u0026amp;A は、ただ「それっぽい答え」を返せばよいわけではなく、検証可能である必要があります。ポリシー、コンプライアンス、財務、技術文書、サポート情報のような分野では、引用と追跡性はほぼ必須です。\n4. 自動化された RAG ワークフロー\rRAGFlow は RAG の一連の流れを、より完成度の高いワークフローとしてまとめています。\nナレッジベースの作成 データのアップロードまたは同期 ドキュメント解析 チャンクの確認と調整 LLM と embedding モデルの設定 多経路検索とリランキングの実行 チャットアシスタントの構築 API 経由で業務システムへ統合 このため、単なるライブラリというより RAG プラットフォームに近い存在です。チームにとっては UI と API の両方が有用で、非エンジニアはナレッジベースを保守しやすく、エンジニアは既存システムへ組み込みやすくなります。\n5. Agent、MCP、ワークフロー拡張\r最近の RAGFlow には Agentic workflow、MCP、Agent Memory、コード実行コンポーネントなども含まれています。これは、従来型のナレッジベース Q\u0026amp;A にとどまらず、Agent シナリオにも広がっていることを示しています。\n典型的には、Agent が信頼できる企業知識レイヤーとして RAGFlow を使い、必要なときにナレッジベースから検索し、引用付きで回答を生成し、必要に応じてツール呼び出しやワークフローと組み合わせる、という形です。\n03 基本的な利用フロー\r公式のクイックスタートに沿うと、RAGFlow の一般的な使い方は次のようにまとめられます。\n1. 実行環境を準備する\rREADME にある基本要件は以下の通りです。\nCPU \u0026gt;= 4 cores RAM \u0026gt;= 16 GB Disk \u0026gt;= 50 GB Docker \u0026gt;= 24.0.0 Docker Compose \u0026gt;= v2.26.1 コード実行用のサンドボックスを使う場合は gVisor も必要です。また、公式 Docker イメージは主に x86 向けです。ARM64 を使う場合は、公式ドキュメントに従って自分でイメージをビルドする必要があります。\n2. プロジェクトを取得する\r1 2 git clone https://github.com/infiniflow/ragflow.git cd ragflow/docker 3. vm.max_map_count を確認する\rRAGFlow のデプロイは Elasticsearch / OpenSearch のようなコンポーネントに依存するため、Linux では通常次を確認します。\n1 sysctl vm.max_map_count 値が 262144 未満なら、一時的に次で設定できます。\n1 sudo sysctl -w vm.max_map_count=262144 再起動後も維持したい場合は /etc/sysctl.conf に追加します。\n4. Docker Compose で起動する\rCPU モードはそのまま起動できます。\n1 docker compose -f docker-compose.yml up -d DeepDoc を GPU で高速化したい場合、README では .env に DEVICE=gpu を追加してから起動する方法が示されています。\n1 2 sed -i \u0026#39;1i DEVICE=gpu\u0026#39; .env docker compose -f docker-compose.yml up -d 起動後はログを確認します。\n1 docker logs -f docker-ragflow-cpu-1 サービスが立ち上がったら、ブラウザでサーバーのアドレスを開きます。デフォルト構成では通常次のようになります。\n1 http://IP_OF_YOUR_MACHINE 5. モデル API Key を設定する\rRAGFlow では LLM と embedding モデルの設定が必要です。README では service_conf.yaml.template 内でデフォルトの LLM factory を選び、対応する API_KEY を更新する流れが説明されています。\n実際には、使うプロバイダーに合わせて次を設定します。\nチャットモデル embedding モデル rerank モデル PDF / DOCX 内の画像も理解したい場合はマルチモーダルモデル 6. ナレッジベースを作成して文書を取り込む\rサービス起動後の典型的な流れは次の通りです。\nWeb UI にログインする。 dataset / knowledge base を作成する。 文書をアップロードするか、データソース同期を設定する。 解析完了を待つ。 チャンク結果を確認し、必要なら調整する。 チャットアシスタントを作成し、知識ベースを関連付ける。 回答品質と引用元を確認する。 業務システムに組み込みたい場合は、RAGFlow の API や SDK を使って、検索とチャット機能を自分のアプリに接続できます。\n04 向いている場面\rRAGFlow は次のような用途に向いています。\n企業内ナレッジベース Q\u0026amp;A 製品マニュアル、技術文書、FAQ の検索 カスタマーサポートや営業支援アシスタント 契約書、レポート、規程文書に対する追跡可能な Q\u0026amp;A 複数形式の資料を一元的に扱いたい場合 UI による運用と API 統合の両方が必要なチーム Agent のコンテキスト層として RAG を使いたいシステム 特に、文書形式が複雑で、引用が重要で、人が解析結果を確認・調整したい場合に向いています。\n05 使うときの注意点\r第一に、RAGFlow は軽量スクリプトではありません。ある程度のインフラ要件があります。公式の推奨は最低 4 コア CPU、16GB RAM、50GB ディスクです。少量の Markdown に対して Q\u0026amp;A をしたいだけなら、ここまで大きなプラットフォームは不要かもしれません。\n第二に、文書品質は依然として重要です。RAGFlow は解析やチャンク分割を改善できますが、質の低い資料、古い資料、矛盾する資料を自動で信頼できるものに変えることはできません。本番導入前にはナレッジベースの運用設計が必要です。\n第三に、モデル設定は結果に直結します。embedding、rerank、チャットモデル、マルチモーダルモデルの選択は、検索品質と回答品質の両方に影響します。RAGFlow はワークフローを提供しますが、最終的な品質はデータ、モデル、パラメータ調整の組み合わせで決まります。\n第四に、本番環境では権限とデータセキュリティに注意が必要です。企業ナレッジベースには社内文書が含まれることが多いため、デプロイ方式、アクセス制御、ログ、API Key、モデル提供者側のデータポリシーまで事前に設計するべきです。\n06 短い判断\rRAGFlow の強みは、RAG で最も面倒な部分をプラットフォーム機能としてまとめていることです。複雑な文書解析、説明可能なチャンク分割、引用のグラウンディング、多経路検索、リランキング、モデル設定、Web UI、API、Agent 拡張までを一式で備えています。\n検証可能で保守しやすく、業務システムにも接続できる企業ナレッジベースを作りたいなら、RAGFlow は「ベクトルデータベース + 簡単なチャット UI」より完成度の高い選択肢です。逆に、個人用途の小規模な Q\u0026amp;A や、扱うデータ形式が非常に単純な場合は、より軽量な RAG フレームワークのほうが扱いやすいかもしれません。\n関連リンク\rGitHub プロジェクト：https://github.com/infiniflow/ragflow 公式ドキュメント：https://ragflow.io/docs/dev/ オンライン Demo：https://cloud.ragflow.io ","date":"2026-04-15T22:09:25+08:00","permalink":"https://www.knightli.com/ja/2026/04/15/ragflow-rag-engine-guide/","title":"RAGFlowプロジェクト整理：オープンソースRAGエンジンの機能と使い方"},{"content":"Firecrawl の位置づけは明確です。Webページを、AI Agentが扱いやすいデータに変換するためのツールです。単なるクローラースクリプトではなく、検索、単一ページのスクレイピング、サイト全体の巡回、ページ操作、構造化抽出、AgentワークフローをAPIとしてまとめ、モデルや自動化システムがWebページ内のノイズに悩まされにくくします。\n01 何を解決するのか\r多くのAIアプリケーションはWebページを読む必要があります。しかし実際のWebは扱いやすくありません。JavaScriptで描画されるページ、ポップアップ、ページネーション、ログイン状態、Bot対策、PDFやDOCXなどHTML以外のコンテンツ、本文とは関係のないナビゲーション、広告、スクリプト、スタイルが混在しています。\nFirecrawl が解決しようとしているのは、この中間層の問題です。アプリケーションは「このページ/このサイト/このテーマのデータが欲しい」と指定するだけで、Firecrawlがページを開き、取得し、クリーニングし、LLMで使いやすいMarkdown、HTML、スクリーンショット、JSONとして返します。\nこの種のツールの価値は、「URLにリクエストできるか」ではありません。複雑なWebページを安定して使えるデータに変換できるかが重要です。RAG、AI検索、競合調査、自動資料収集、Webコンテンツ監視では、この層がシステム内の面倒な配管になりがちです。\n02 主な機能\rFirecrawlのREADMEでは、機能がいくつかの領域に分けられています。\nSearch：Webを検索し、検索結果ページの本文まで取得する。 Scrape：単一URLをMarkdown、HTML、スクリーンショット、構造化JSONに変換する。 Interact：ページを取得した後、プロンプトやコードでクリック、スクロール、入力、待機などを実行する。 Agent：欲しい情報を直接説明すると、Agentが自動で検索、遷移、結果の取得を行う。 Crawl：Webサイト配下の複数ページを取得する。 Map：Webサイト内のURLを素早く発見する。 Batch Scrape：大量のURLを非同期で一括取得する。 名前だけを見ると「スクレイピングサービス」に見えます。しかし機能全体を見ると、AIアプリケーションのデータ入口に近い存在です。検索は情報源を見つけ、スクレイピングは内容を整え、操作機能は動的ページを扱い、Agentは「情報を探す」という作業をさらに自動化します。\n03 AI Agentに向いている理由\r従来のクローラーは、URLが既知であり、ページ構造も理解していることを前提にする場合が多いです。しかしAgentの場面ではそうとは限りません。ユーザーは「ある会社の最新料金ページにあるプラン差分を調べて」と頼むだけかもしれません。システム側は自分で検索し、ページを開き、内容を比較し、出典を返す必要があります。\nFirecrawlの Agent エンドポイントは、このようなタスクを想定しています。自然言語のプロンプトだけで動かすことも、指定したURL範囲に限定して動かすこともできます。構造化された結果が必要な場合は、schemaと組み合わせて固定フィールドで出力できます。\nアプリケーション層にとっては、次の2つの利点があります。\nWebサイトごとに個別のパーサーを書く必要がない。 返ってきた結果をLLM、データベース、後続の自動化フローに渡しやすい。 もちろん、すべてのカスタムクローラーを置き換えるわけではありません。制約が強く、高頻度で、大規模で、フィールドが非常に安定している取得タスクでは、専用の解析ロジックを書いたほうが安く、制御もしやすい場合があります。Firecrawlは、情報源が分散し、ページ構造が変わりやすく、AIワークフローに素早く接続したい場面に向いています。\n04 MCP、CLI、インテグレーション\rFirecrawlはAgent向けツールチェーンにも明確に寄せています。READMEにはMCP Serverの接続方法があり、AI coding agent向けのSkill/CLI初期化コマンドも用意されています。\nつまり、バックエンドサービスからAPIとして呼ぶだけでなく、Claude Code、OpenCode、Antigravity、MCPクライアントなどのワークフローに直接入ることも想定しています。Agentに調査、Web取得、内容整理をよく任せる人にとっては、API呼び出しを手書きするより軽い導入方法です。\nZapier、n8n、Lovableなどのプラットフォーム連携も挙げられています。この方向性は実用的です。Webデータは必ずしもコードにだけ入るわけではなく、自動化テーブル、ローコードフロー、コンテンツ制作システム、社内ナレッジベースにも流れます。\n05 オープンソース、セルフホスト、ライセンス境界\rFirecrawlはオープンソースプロジェクトです。メインリポジトリは主に AGPL-3.0 でライセンスされています。READMEでは、SDKと一部のUIコンポーネントは MIT ライセンスであり、詳細は各ディレクトリのLICENSEファイルを見る必要があるとも説明されています。\nここは注意が必要です。クラウドサービスとして使うだけなら、主な関心はAPIコスト、安定性、コンプライアンス上の境界です。一方で、セルフホストして外部にサービス提供するなら、AGPL-3.0 の義務をきちんと確認する必要があります。\nREADMEでは、Webサイトのポリシー、プライバシーポリシー、利用規約を尊重するようにも注意しています。また、デフォルトで robots.txt に従うと説明されています。この種のツールは強力になるほど、コンプライアンスと取得範囲の設計を後回しにせず、最初からシステムに組み込む必要があります。\n06 向いている場面\rFirecrawlを優先的に検討したいのは、次のような場面です。\nRAGシステム向けにWeb資料を取得し、きれいなMarkdownを直接得たい。 AI検索や調査アシスタントで、検索後にページ全体を読む必要がある。 JavaScriptが重いサイトを取得したいが、自前でブラウザクラスターを保守したくない。 競合、価格、ドキュメント、ニュース、採用ページなどの公開情報を監視したい。 MCPクライアントやAI coding agentにリアルタイムのWeb読み取り能力を追加したい。 クローラー基盤を先に作るのではなく、Webデータ製品を素早く検証したい。 あまり向いていない場面もはっきりしています。\n対象サイトのフィールドが少なく、構造も安定していて、簡単なスクリプトで十分な場合。 取得量が非常に大きく、開発保守コストより実行コストのほうが重要な場合。 データソース、リトライ戦略、Bot対策への振る舞い、監査要件を細かく制御する必要がある場合。 ライセンスやコンプライアンス要件として、AGPLコンポーネントや外部クラウドサービスを導入できない場合。 07 短い判断\rFirecrawlの価値は、「WebページからAIで使えるデータへ」という面倒な流れをプロダクト化している点にあります。検索、取得、クリーニング、操作、バッチ処理、Agent型の資料収集を1つのインターフェースにまとめているため、AIアプリケーション開発者には使いやすい選択肢です。\nモデルに実際のWebページを読ませる必要がよくあり、特に情報源が分散し、構造が不安定で、MCPやAgentワークフローにも接続したいなら、Firecrawlはツール箱に入れておく価値があります。逆に、固定サイトから低コストで大量収集するだけなら、従来のクローラーや専用パーサーのほうが適している場合があります。\n関連リンク\rGitHubプロジェクト：https://github.com/firecrawl/firecrawl ","date":"2026-04-15T13:45:03+08:00","permalink":"https://www.knightli.com/ja/2026/04/15/firecrawl-ai-web-data-api/","title":"Firecrawlプロジェクト整理：AI Agent向けのWeb検索・スクレイピング・操作API"},{"content":"ブラウザ自動化プロセスをデバッグ用、ドキュメント デモンストレーション用、または実行結果のファイルとしてビデオに記録したい場合、Playwright CLI は比較的簡単なソリューションを提供します。 VP8/VP9 としてエンコードされた WebM ビデオを出力します。\nこの記事は、公式 video-recording リファレンス ドキュメントに従って構成されており、基本的な録画プロセス、チャプター マーカー、ヒーロー スクリプト全体の録画、オーバーレイ API、およびビデオとトレースの違いに焦点を当てています。この記事のコマンド ライン、コード スニペット、およびパラメーターの説明は、参照コンテンツとして保持されています。\n01 基本的な録音の流れ\r最も基本的なプロセスは、まずブラウザを開き、次に録画を開始し、操作を実行し、最後に停止して保存します。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 # Open browser first playwright-cli open # Start recording playwright-cli video-start demo.webm # Add a chapter marker for section transitions playwright-cli video-chapter \u0026#34;Getting Started\u0026#34; --description=\u0026#34;Opening the homepage\u0026#34; --duration=2000 # Navigate and perform actions playwright-cli goto https://example.com playwright-cli snapshot playwright-cli click e1 # Add another chapter playwright-cli video-chapter \u0026#34;Filling Form\u0026#34; --description=\u0026#34;Entering test data\u0026#34; --duration=2000 playwright-cli fill e2 \u0026#34;test input\u0026#34; # Stop and save playwright-cli video-stop このコマンド セットは、最も一般的な記録パスをカバーしています。 video-chapter は、録画したビデオを理解しやすくするために、さまざまなステージの間にチャプター カードを挿入するのに適しています。\n02 ベストプラクティス\r1. わかりやすいファイル名を使用する\rビデオが他の人に見てもらうためのものである場合、または後でレビューする場合は、ファイル名にシーンとコンテキストを直接含めるのが最善です。\n1 2 3 # Include context in filename playwright-cli video-start recordings/login-flow-2024-01-15.webm playwright-cli video-start recordings/checkout-test-run-42.webm 2. 完全なヒーロー スクリプトを記録する\r公式アドバイス: ビデオをユーザーに配信する場合、または作業証明として使用する場合は、シーンをコードにまとめて run-code で実行するのが最善です。これにより、ビデオ内のアクションのリズム、一時停止のタイミング、注釈効果を制御しやすくなります。リファレンス ドキュメントには、Playwright がシーンの記録に適した新しい API をいくつか追加したことも具体的に記載されています。\n推奨されるプロセスは次のとおりです。\nまず、CLI を使用してシーンをウォークスルーし、すべてのロケーターとアクションを書き留めます。後でハイライトしたい場合は、これらのロケーターを使用して境界ボックスをリクエストする必要があります。 ビデオ用に別のスクリプト ファイルを作成し、次のように記述します。コンテンツを入力する際に​​は、pressSequentially および delay を使用し、一時停止時間をできるだけ自然に配置するようにしてください。 playwright-cli run-code --filename your-script.jsを使用して実行します。 Important: Overlays are pointer-events: none — they do not interfere with page interactions. You can safely keep sticky overlays visible while clicking, filling, or performing any actions on the page.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 async page =\u0026gt; { await page.screencast.start({ path: \u0026#39;video.webm\u0026#39;, size: { width: 1280, height: 800 } }); await page.goto(\u0026#39;https://demo.playwright.dev/todomvc\u0026#39;); // Show a chapter card — blurs the page and shows a dialog. // Blocks until duration expires, then auto-removes. // Use this for simple use cases, but always feel free to hand-craft your own beautiful // overlay via await page.screencast.showOverlay(). await page.screencast.showChapter(\u0026#39;Adding Todo Items\u0026#39;, { description: \u0026#39;We will add several items to the todo list.\u0026#39;, duration: 2000, }); // Perform action await page.getByRole(\u0026#39;textbox\u0026#39;, { name: \u0026#39;What needs to be done?\u0026#39; }).pressSequentially(\u0026#39;Walk the dog\u0026#39;, { delay: 60 }); await page.getByRole(\u0026#39;textbox\u0026#39;, { name: \u0026#39;What needs to be done?\u0026#39; }).press(\u0026#39;Enter\u0026#39;); await page.waitForTimeout(1000); // Show next chapter await page.screencast.showChapter(\u0026#39;Verifying Results\u0026#39;, { description: \u0026#39;Checking the item appeared in the list.\u0026#39;, duration: 2000, }); // Add a sticky annotation that stays while you perform actions. // Overlays are pointer-events: none, so they won\u0026#39;t block clicks. const annotation = await page.screencast.showOverlay(` \u0026lt;div style=\u0026#34;position: absolute; top: 8px; right: 8px; padding: 6px 12px; background: rgba(0,0,0,0.7); border-radius: 8px; font-size: 13px; color: white;\u0026#34;\u0026gt; ✓ Item added successfully \u0026lt;/div\u0026gt; `); // Perform more actions while the annotation is visible await page.getByRole(\u0026#39;textbox\u0026#39;, { name: \u0026#39;What needs to be done?\u0026#39; }).pressSequentially(\u0026#39;Buy groceries\u0026#39;, { delay: 60 }); await page.getByRole(\u0026#39;textbox\u0026#39;, { name: \u0026#39;What needs to be done?\u0026#39; }).press(\u0026#39;Enter\u0026#39;); await page.waitForTimeout(1500); // Remove the annotation when done await annotation.dispose(); // You can also highlight relevant locators and provide contextual annotations. const bounds = await page.getByText(\u0026#39;Walk the dog\u0026#39;).boundingBox(); await page.screencast.showOverlay(` \u0026lt;div style=\u0026#34;position: absolute; top: ${bounds.y}px; left: ${bounds.x}px; width: ${bounds.width}px; height: ${bounds.height}px; border: 1px solid red;\u0026#34;\u0026gt; \u0026lt;/div\u0026gt; \u0026lt;div style=\u0026#34;position: absolute; top: ${bounds.y + bounds.height + 5}px; left: ${bounds.x + bounds.width / 2}px; transform: translateX(-50%); padding: 6px; background: #808080; border-radius: 10px; font-size: 14px; color: white;\u0026#34;\u0026gt;Check it out, it is right above this text \u0026lt;/div\u0026gt; `, { duration: 2000 }); await page.screencast.stop(); } このコード部分の焦点は、単に「記録する」ことではなく、ビデオをより鮮明にすることです。チャプター カードはセグメンテーションを担当し、pressSequentially は入力アクションをより自然にし、showOverlay はプロンプト、ハイライト、説明を実行できます。\nこの文書の最後には、「創造性を受け入れ、オーバーレイは強力です」という一文も追加されています。\n03 オーバーレイ API の概要\rビデオを録画する場合、オーバーレイ API はチャプターの切り替え、ローカル プロンプト、および継続的な注釈に非常に適しています。公式の概要は次のとおりです。\nMethod Use Case page.screencast.showChapter(title, { description?, duration?, styleSheet? }) Full-screen chapter card with blurred backdrop — ideal for section transitions page.screencast.showOverlay(html, { duration? }) Custom HTML overlay — use for callouts, labels, highlights disposable.dispose() Remove a sticky overlay added without duration page.screencast.hideOverlays() / page.screencast.showOverlays() Temporarily hide/show all overlays 自動化されたプロセスを「視聴可能なビデオ」に変えることが目標の場合、基本的にはこの API セットを最初に習得するのが最も価値があります。\n04 トレースとビデオの違い\r公式ドキュメントでは、この 2 つの位置付けが明確に区別されています。\nFeature Video Tracing Output WebM file Trace file (viewable in Trace Viewer) Shows Visual recording DOM snapshots, network, console, actions Use case Demos, documentation Debugging, analysis Size Larger Smaller 簡単な理解:\nvideo は、「ユーザーから見たプロセス」のデモンストレーション、配信、レビューに適しています。 tracing は、問題のトラブルシューティング、アクションの詳細の分析、実行コンテキストの表示に適しています。 2 人はお互いの代わりではありませんが、それぞれが異なる目的を果たします。\n05 利用制限\rこの文書では、次の 2 つの非常に実際的な制限も指摘しています。\nRecording adds slight overhead to automation Large recordings can consume significant disk space 言い換えれば、記録機能は非常に実用的ですが、自動化されたプロセスにある程度のオーバーヘッドが追加されます。ビデオが非常に長い場合、ディスク使用量も大幅に増加します。\n06 簡単なまとめ\r重要なポイントだけに焦点を当てると、次のことを思い出すことができます。\nvideo-start / video-stop は最も基本的なビデオ録画プロセスに対応します video-chapter はビデオにチャプタートランジションを追加でき、プレゼンテーションをより明確にするのに適しています より複雑なビデオ シーンの場合は、スクリプトを作成して run-code で実行するのが適しています。 showOverlay と showChapter を使用すると、ビデオの読みやすさが大幅に向上します。 video はデモンストレーションに適しており、tracing はデバッグに適しています。ターゲットに合わせて選ぶと良いでしょう。 すでに Playwright CLI を自動デモンストレーション、承認ファイル、またはプルーフオブワークに使用している場合、video recording は非常に価値のある追加となります。\n参考リンク\rPlaywright CLI ビデオ録画リファレンス ドキュメント: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/video-recording.md Playwright CLI プロジェクトのホームページ: https://github.com/microsoft/playwright-cli ","date":"2026-04-15T08:22:45+08:00","permalink":"https://www.knightli.com/ja/2026/04/15/playwright-cli-video-recording/","title":"Playwright CLI ビデオ録画: 画面録画、チャプター マーカー、オーバーレイおよびデバッグの比較"},{"content":"自動化に Playwright CLI を使用している場合は、すぐに実際的な問題に遭遇することになります。それは、相互に干渉せずに同時に複数のブラウザー セッションを開くことができるかということです。答えは「はい」です。Playwright CLI により、このメカニズムが非常に簡単になりました。\nこの記事は、公式 session-management リファレンス ドキュメントに従い、名前付きセッション、セッション分離、永続性プロファイル、同時実行モード、一般的なクリーンアップ コマンドなどの最も実用的な部分を整理します。この記事のコマンド ラインとコマンド ブロックの説明は、参考コンテンツとして保持されています。\n01 ブラウザセッションに名前を付けます\r公式の推奨事項は、-s パラメーターを使用して、異なるブラウザー コンテキストを分離することです。\n1 2 3 4 5 6 7 8 9 # Browser 1: Authentication flow playwright-cli -s=auth open https://app.example.com/login # Browser 2: Public browsing (separate cookies, storage) playwright-cli -s=public open https://example.com # Commands are isolated by browser session playwright-cli -s=auth fill e1 \u0026#34;user@example.com\u0026#34; playwright-cli -s=public snapshot ここで重要な点は、異なる session 名が異なるブラウザー コンテキストに対応するということです。ログインプロセスには auth を使用し、匿名アクセスには public を使用できます。 Cookie やローカル状態を共有しません。\n02 ブラウザセッションは何を分離しますか?\r各ブラウザ セッションは、次のコンテンツを独立して保持します。\nCookies LocalStorage / SessionStorage IndexedDB Cache Browsing history Open tabs これは、auth セッションで Web サイトにログインしても、自動的には public セッションに影響を与えないことを意味します。これは、複数アカウントのテスト、ログイン検証、匿名比較を行う場合に特に重要です。\n03 ブラウザセッション関連コマンド\r公式ドキュメントには、セッション管理で最も一般的に使用される一連のコマンドがまとめられています。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 # List all browser sessions playwright-cli list # Stop a browser session (close the browser) playwright-cli close # stop the default browser playwright-cli -s=mysession close # stop a named browser # Stop all browser sessions playwright-cli close-all # Forcefully kill all daemon processes (for stale/zombie processes) playwright-cli kill-all # Delete browser session user data (profile directory) playwright-cli delete-data # delete default browser data playwright-cli -s=mysession delete-data # delete named browser data これらは、次の 3 種類の操作として理解できます。\nlist: 現在利用可能な会話を確認します close/close-all/kill-all: セッションを終了するか、スタックしたブラウザー プロセスをクリーンアップします delete-data: セッションに対応するユーザー データ ディレクトリを削除します ブラウザを終了するだけの場合は、通常、最初に close を使用します。残留プロセスまたはゾンビ プロセスがある場合は、kill-all を使用する方が適切です。\n04 環境変数を使用してデフォルトのセッションを設定します\rコマンドごとに -s=mysession を繰り返し書きたくない場合は、公式が環境変数メソッドも提供しています。\n1 2 export PLAYWRIGHT_CLI_SESSION=\u0026#34;mysession\u0026#34; playwright-cli open example.com # Uses \u0026#34;mysession\u0026#34; automatically このように、-s が明示的に指定されていない場合、コマンドはデフォルトで mysession ブラウザー セッションを使用します。\n05 一般的なパターン: 同時クロール\r参考資料には、同時クロールの非常に典型的な例が示されています。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 #!/bin/bash # Scrape multiple sites concurrently # Start all browsers playwright-cli -s=site1 open https://site1.com \u0026amp; playwright-cli -s=site2 open https://site2.com \u0026amp; playwright-cli -s=site3 open https://site3.com \u0026amp; wait # Take snapshots from each playwright-cli -s=site1 snapshot playwright-cli -s=site2 snapshot playwright-cli -s=site3 snapshot # Cleanup playwright-cli close-all このモードは、複数のサイトを同時に開き、ページのステータスを個別に取得して、それらをまとめてクリーンアップするのに適しています。各サイトは個別のセッションで実行されるため、互いのローカル状態を汚染することはありません。\n06 一般的なパターン: A/B テスト セッション\rもう 1 つの一般的なシナリオは、異なる実験版を同時に比較することです。\n1 2 3 4 5 6 7 # Test different user experiences playwright-cli -s=variant-a open \u0026#34;https://app.com?variant=a\u0026#34; playwright-cli -s=variant-b open \u0026#34;https://app.com?variant=b\u0026#34; # Compare playwright-cli -s=variant-a screenshot playwright-cli -s=variant-b screenshot この書き方は、2 つのバージョンが独立したセッションで実行され、スクリーンショットとステータス チェックを個別に管理しやすいため、A/B ページの差分比較に非常に適しています。\n07 永続的なブラウザプロファイル\r公式ドキュメントには具体的に次のように記載されています: デフォルトでは、ブラウザーのプロファイルはメモリにのみ保存されます。\nブラウザー プロファイルをディスクに保存したい場合は、--persistent を open に追加する必要があります。\n1 2 3 4 5 # Use persistent profile (auto-generated location) playwright-cli open https://example.com --persistent # Use persistent profile with custom directory playwright-cli open https://example.com --profile=/path/to/profile この機能は、ログイン ステータス、ローカル キャッシュ、または拡張デバッグ環境の長期的な再利用が必要なシナリオに適しています。特に、同じサイトを何度もデバッグする場合は、毎回最初から開始するよりもプロファイルを永続化する方が効率的であることがよくあります。\n08 デフォルトのブラウザセッション\r-s が明示的に渡されない場合、コマンドはデフォルトのブラウザー セッションを使用します。\n1 2 3 4 # These use the same default browser session playwright-cli open https://example.com playwright-cli snapshot playwright-cli close # Stops default browser つまり、-s のない複数のコマンドは、デフォルトで同じデフォルト セッション内で継続的に実行されます。\n09 セッション構成で開く\rセッション名に加えて、公式ではいくつかの一般的な起動設定方法も提供しています。\n1 2 3 4 5 6 7 8 9 10 11 # Open with config file playwright-cli open https://example.com --config=.playwright/my-cli.json # Open with specific browser playwright-cli open https://example.com --browser=firefox # Open in headed mode playwright-cli open https://example.com --headed # Open with persistent profile playwright-cli open https://example.com --persistent これらのパラメータはセッション管理と組み合わせて使用​​できます。たとえば、名前付きセッションを常に firefox で実行したり、セッションを常に headed モードで開始して手動で観察しやすくしたりできます。\n10 の公式ベスト プラクティス\r参考資料には、3 つの非常に実践的なベスト プラクティスがリストされています。\n1. セマンティックなセッション名を使用する\r1 2 3 4 5 6 # GOOD: Clear purpose playwright-cli -s=github-auth open https://github.com playwright-cli -s=docs-scrape open https://docs.example.com # AVOID: Generic names playwright-cli -s=s1 open https://github.com 目的を直接表現するセッション名を付けるのが最善です。 github-auth や docs-scrape のような名前は、後でスクリプトを保守するときにはるかに明確になります。\n2. 使用後は適時に掃除してください\r1 2 3 4 5 6 7 8 9 # Stop browsers when done playwright-cli -s=auth close playwright-cli -s=scrape close # Or stop all at once playwright-cli close-all # If browsers become unresponsive or zombie processes remain playwright-cli kill-all タスクの完了後にブラウザを閉じないと、セッションとバックグラウンド プロセスが残ります。短期的には大きな問題ではありませんが、タスクが多すぎると環境が混乱しやすくなります。\n3. 古いブラウザデータを削除する\r1 2 # Remove old browser data to free disk space playwright-cli -s=oldsession delete-data 一部の古いセッションが使用されなくなった場合、対応するデータ ディレクトリを削除すると、ディスク領域を節約し、後で期限切れステータスの悪用を避けることができます。\n11 簡単なまとめ\r重要なポイントだけに焦点を当てると、次のことを思い出すことができます。\n-s=\u0026lt;name\u0026gt; は、独立したブラウザ セッションを作成および使用するために使用されます。 Cookie、ストレージ、キャッシュ、履歴、タブはセッション間で分離されます close-all は統合シャットダウンに適しており、kill-all は異常な残留プロセスの処理に適しています。 --persistent は、長期間の再利用に適したプロファイルをディスクにダウンロードするために使用されます。 セッション名はできる限りセマンティックである必要があり、古いデータは定期的にクリーンアップする必要があります。 ワークフローにすでにログイン状態の再利用、複数アカウントの並列処理、A/B 比較、またはバッチ クロールのニーズがある場合、基本的に session management は、Playwright CLI の機能を習得するのに最も価値があります。\n参考リンク\rPlaywright CLI セッション管理リファレンス ドキュメント: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/session-management.md Playwright CLI プロジェクトのホームページ: https://github.com/microsoft/playwright-cli ","date":"2026-04-15T08:15:12+08:00","permalink":"https://www.knightli.com/ja/2026/04/15/playwright-cli-session-management/","title":"Playwright CLI セッション管理: マルチブラウザ セッション、分離、永続化、クリーンアップ"},{"content":"この記事では主に、組み込みシステムで一般的な 3 つの M.2 インターフェイスについて説明します。\nSocket 1 - Key E Socket 2 - Key B Socket 3 - Key M また、原文の記述は PCI Express M.2 仕様リビジョン 3.0、バージョン 1.2 に基づいています。\n01 Socket 1 - Key E\rKey E は、Wi-Fi/Bluetooth 拡張カードなどの接続モジュールでよく見られます。元の記事では、このタイプのカードは通常、PCIe および USB を介して接続されると述べました。 SDIO や I2S などの他のバスが使用できるかどうかは、COM がそれをサポートしているかどうかによって異なります。\nPinout Description\r左 Pin 左信号 右信号 右 Pin 743.3VGND75 723.3VRESERVED/REFCLKn173 70UIM_POWER_SRC/GPIO_1/PEWAKE1#RESERVED/REFCLKp171 68UIM_POWER_SNK/CLKREQ1#GND69 66UIM_SWP/PERST1#RESERVED/PERn167 64RESERVEDRESERVED/PERp165 62ALERT# (I)(0/1.8 V)GND63 60I2C_CLK (O)(0/1.8 V)RESERVED/PETn161 58I2C_DATA (I/O)(0/1.8 V)RESERVED/PETp159 56W_DISABLE1# (O)(0/3.3V)GND57 54W_DISABLE2# (O)(0/3.3V)PEWAKE0# (I/O)(0/3.3V)55 52PERST0# (O)(0/3.3V)CLKREQ0# (I/O)(0/3.3V)53 50SUSCLK(32kHz) (O)(0/3.3V)GND51 48COEX_TXD (O)(0/1.8V)REFCLKn049 46COEX_RXD (I)(0/1.8V)REFCLKp047 44COEX3 (I/O)(0/1.8V)GND45 42VENDOR DEFINEDPERn043 40VENDOR DEFINEDPERp041 38VENDOR DEFINEDGND39 36UART RTS (O)(0/1.8V)PETn037 34UART CTS (I)(0/1.8V)PETp035 32UART TXD (O)(0/1.8V)GND33 Key EKey E Key EKey E Key EKey E Key ESDIO RESET#/TX_BLANKING (O)(0/1.8V)23 22UART RXD (I)(0/1.8V)SDIO WAKE# (I)(0/1.8V)21 20UART WAKE# (I)(0/3.3V)SDIO DATA3(I/O)(0/1.8V)19 18GNDSDIO DATA2(I/O)(0/1.8V)17 16LED_2# (I)(OD)SDIO DATA1(I/O)(0/1.8V)15 14PCM_OUT/I2S SD_OUT (O)(0/1.8V)SDIO DATA0(I/O)(0/1.8V)13 12PCM_IN/I2S SD_IN (I)(0/1.8V)SDIO CMD(I/O)(0/1.8V)11 10PCM_SYNC/I2S WS (I/O)(0/1.8V)SDIO CLK/SYSCLK (O)(0/1.8V)9 8PCM_CLK/I2S SCK (I/O)(0/1.8V)GND7 6LED_1# (I)(OD)USB_D-5 43.3VUSB_D+3 23.3VGND1 追加情報\rM.2 Socket 1 - Key E は、Wi-Fi / Bluetooth モジュールなどの接続アプリケーションでよく使用されます。 PCIe_TX+/- の AC カップリング コンデンサは COM 側に配置され、PCIe_RX+/- の AC カップリング コンデンサは M.2 拡張カード側に配置されるため、キャリア ボードでこれらの AC カップリング コンデンサを追加する必要はありません。 CLKREQ# は、PCIe 基準クロックを有効にするために使用され、PCIe クロック バッファーの出力イネーブル ピンに接続する必要があります。 CLKREQ# は M.2 拡張カードによって出力されるローアクティブのオープンドレイン信号であるため、キャリア ボードにプルアップ抵抗が必要です。 02 Socket 2 - Key B\rKey B は、SATA、PCIe SSD、または一部の WWAN モジュールで一般的です。このソケットのセットは、CONFIG_0 から CONFIG_3 までの 4 つの構成ピンを特徴としており、これによりシステムはカードが使用することを想定しているホスト インターフェイスを識別できます。\nPinout Description\r左 Pin 左信号 右信号 右 Pin 743.3 V/VBATCONFIG_275 723.3 V/VBATGND73 703.3 V/VBATGND71 68SUSCLK(32kHz) (O)(0/3.3V)CONFIG_169 66SIM DETECT (O)RESET# (O)(0/1.8V)67 64COEX_RXD (I)(0/1.8V)ANTCTL3 (I)(0/1.8V)65 62COEX_TXD (O)(0/1.8V)ANTCTL2 (I)(0/1.8V)63 60COEX3 (I/O)(0/1.8V)ANTCTL1 (I)(0/1.8V)61 58NCANTCTL0 (I)(0/1.8V)59 56NCGND57 54PEWAKE# (I/O)(0/3.3V)REFCLKp55 52CLKREQ# (I/O)(0/3.3V)REFCLKn53 50PERST# (O)(0/3.3V)GND51 48GPIO_4 (I/O)(0/1.8V)PETp0/SATA-A+49 46GPIO_3 (I/O)(0/1.8V)PETn0/SATA-A-47 44GPIO_2 (I/O)/ALERT# (I)/(0/1.8V)GND45 42GPIO_1 (I/O)/SMB_DATA (I/O)/(0/1.8V)PERp0/SATA-B-43 40GPIO_0 (I/O)/SMB_CLK (I/O)/(0/1.8V)PERn0/SATA-B+41 38DEVSLP (O)GND39 36UIM-PWR (I)PETp1/USB3.1-Tx+/SSIC-TxP37 34UIM-DATA (I/O)PETn1/USB3.1-Tx-/SSIC-TxN35 32UIM-CLK (I)GND33 30UIM-RESET (I)PERp1/USB3.1-Rx+/SSIC-RxP31 28GPIO_8 (I/O) (0/1.8V)PERn1/USB3.1-Rx-/SSIC-RxN29 26GPIO_10 (I/O) (0/1.8V)GND27 24GPIO_7 (I/O) (0/1.8V)DPR (O) (0/1.8V)25 22GPIO_6 (I/O)(0/1.8V)GPIO_11 (I/O) (0/1.8V)23 20GPIO_5 (I/O)(0/1.8V)CONFIG_021 Key BKey B Key BKey B Key BKey B Key BGND11 10GPIO_9/DAS/DSS (I/O)/LED_1# (I)(0/3.3V)USB_D-9 8W_DISABLE1# (O)(0/3.3V)USB_D+7 6FULL_CARD_POWER_OFF# (O)(0/1.8V or 3.3V)GND5 43.3 VGND3 23.3 VCONFIG_31 Host Interface Configuration\r元の記事では、システムは現在のカードで選択されているピン配置/ホスト インターフェイスを識別するために 4 つの CONFIG_X ピンを読み取る必要があると指摘しています。 M.2 カードの電源が入っていない場合でも、システムはこれらの設定ピンを適切な電源にプルアップして、ステータスを読み取ることができるようにする必要があります。\nCONFIG_0 (Pin 21) CONFIG_1 (Pin 69) CONFIG_2 (Pin 75) CONFIG_3 (Pin 1) Host Interface 0 0 0 0 SSD - SATA 0 1 0 0 SSD - PCIe 0 0 1 0 WWAN - PCIe (Port Configuration 0*) 0 1 1 0 WWAN - PCIe (Port Configuration 1*) 0 0 0 1 WWAN - PCIe, USB3.1 Gen1 (Port Configuration 0*) 0 1 0 1 WWAN - PCIe, USB3.1 Gen1 (Port Configuration 1*) 0 0 1 1 WWAN - PCIe, USB3.1 Gen1 (Port Configuration 2*) 0 1 1 1 WWAN - PCIe, USB3.1 Gen1 (Port Configuration 3*) 1 0 0 0 WWAN - SSIC (Port Configuration 0*) 1 1 0 0 WWAN - SSIC (Port Configuration 1*) 1 0 1 0 WWAN - SSIC (Port Configuration 2*) 1 1 1 0 WWAN - SSIC (Port Configuration 3*) 1 0 0 1 WWAN - PCIe (Port Configuration 2*) 1 1 0 1 WWAN - PCIe (Port Configuration 3*) 1 0 1 1 WWAN - PCIe, USB3.1 Gen1 (vendor defined) 1 1 1 1 No Add-in Card Present 注: Port Configuration のさまざまな詳細については、元の記事で PCI Express M.2 仕様を確認することが推奨されています。\n追加情報\rSocket 2 - Key B は、一般的に、PCIe または SATA タイプのストレージ デバイスの接続に使用されます。 CONFIG_1 を使用してホスト インターフェイスを切り替えることができます。 CONFIG_1 = Low の場合、SATA を有効にする CONFIG_1 = High の場合、PCIe を有効にする 2 番目の PCIe レーンは、Intel Optane などの PCIe x2 デバイスをサポートできます。実際に x2 を実行するには、ホスト側の PCIe レーンも PCIe x2 link として構成する必要があります。 PCIe モードが有効な場合、CONFIG_1 は M.2 拡張カードに接続されないため、キャリア ボードにプルアップ抵抗を追加する必要があります。 この M.2 ソケットが SATA ストレージ デバイスに接続されている場合は、Pin 43 を SATA Rx 差動ペアのマイナス端に接続する必要があります。 この M.2 ソケットが PCIe ストレージ デバイスに接続されている場合は、Pin 43 を PCIe Rx 差動ペアの正端に接続する必要があります。 03 Socket 3 - Key M\rKey M は、PCIe または SATA タイプのストレージ デバイス、特に高帯域幅 SSD の接続に非常に一般的に使用されます。 Key Bと同様にホストインターフェースを選択する信号もありますが、PEDETに変更されています。\nPinout Description\r左 Pin 左信号 右信号 右 Pin 743.3 VGND75 723.3 VGND73 703.3 VGND71 68SUSCLK (O)(0/3.3V)PEDET69 Key MNC67 Key MKey M Key MKey M Key MKey M Key MKey M 58NCGND57 56NCREFCLKp55 54PEWAKE# (I/O)(0/3.3V) or NCREFCLKn53 52CLKREQ# (I/O)(0/3.3V) or NCGND51 50PERST# (O)(0/3.3V) or NCPETp0/SATA-A+49 48NCPETn0/SATA-A-47 46NCGND45 44ALERT# (I) (0/1.8V)PERp0/SATA-B-43 42SMB_DATA (I/O) (0/1.8V)PERn0/SATA-B+41 40SMB_CLK (I/O)(0/1.8V)GND39 38DEVSLP (O)PETp137 36NCPETn135 34NCGND33 32NCPERp131 30NCPERn129 28NCGND27 26NCPETp225 24NCPETn223 22NCGND21 20NCPERp219 183.3 VPERn217 163.3 VGND15 143.3 VPETp313 123.3 VPETn311 10DAS/DSS (I/O)/LED_1# (I)(0/3.3V)GND9 8NCPERp37 6NCPERn35 43.3 VGND3 23.3 VGND1 追加情報\rSocket 3 - Key M は、一般的に、PCIe または SATA タイプのストレージ デバイスの接続に使用されます。 PEDET はホスト インターフェイスの選択に使用され、M.2 カードはさまざまな接続方法を使用してモードを示します。 PEDET = Low は、SATA を有効にすることを意味します。つまり、M.2 カードは PEDET を GND に接続します。 PEDET = High は、PCIe を有効にすることを意味します。つまり、PEDET は M.2 カードに接続されていません。 帯域幅を最大にするには、4 つの PCIe レーンを x4 link として構成する必要があります。 PCIe モードが有効な場合、M.2 拡張カードは PEDET に接続されないため、キャリア ボードにプルアップ抵抗を追加する必要があります。 このソケットが SATA ストレージ デバイスに接続されている場合は、Pin 43 を SATA Rx 差動ペアのマイナス端に接続する必要があります。 このソケットが PCIe ストレージ デバイスに接続されている場合は、Pin 43 を PCIe Rx 差動ペアの正端に接続する必要があります。 04 素早い整理整頓\rこの記事の重要なポイントをすぐに覚えておきたい場合は、まず次の内容を理解してください。\nKey E は主に Wi-Fi/Bluetooth などの接続モジュールを好みます。 Key B は SATA / PCIe SSD で一般的であり、WWAN クラス モジュールにも表示される場合があります。 Key M は主に高帯域幅ストレージに使用され、PCIe SSD でよく見られます。 Key B は、CONFIG_0 ~ CONFIG_3 を介してインターフェイス構成を識別します。 Key M は、PEDET によって SATA または PCIe を識別します。 CLKREQ#、CONFIG_1、PEDET などの信号では、キャリア ボードが一部のモードでプルアップを提供する必要があります。 将来的にキャリアボードやソケットのドッキング設計を行う場合は、この記事を元の情報および PCI Express M.2 仕様、特に Port Configuration、PCIe レーン構成、SATA/PCIe 共有ピンの部分と比較することをお勧めします。\n参考内容\r元の情報: https://wiki.congatec.com/wiki/M.2_Pinout_Descriptions_and_Reference_Designs_(AN43) ","date":"2026-04-15T08:00:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/15/m2-pinout-descriptions/","title":"M.2 E キー B キー M キーのピンの説明の配置"},{"content":"ブラウザの自動化に Playwright CLI を使用する場合、storage state は基本的に最もよく使用される機能の 1 つです。その機能は非常に直接的です。現在のログイン状態とローカル状態をブラウザに保存し、後でそれを再利用して、毎回再度ログインする必要がなくなります。\n01 現在の保存状態を保存します\r最も一般的なシナリオは、一度ログインしてから現在のステータスをファイルにエクスポートすることです。\n1 playwright-cli storage-state save auth.json このコマンドは、現在のブラウザー コンテキストの状態を auth.json に保存します。後でログイン状態を再利用する場合は、通常はこのステップから開始します。\n02 既存のストレージ状態をロードします\r状態ファイルをすでに作成している場合は、起動時にそれを直接ロードできます。\n1 playwright-cli --storage-state auth.json auth.json の状態でブラウザー コンテキストを開始します。一般的な使用法は、繰り返しのログインをスキップして、ログインした環境に直接入ることです。\n03 現在の Cookie を表示する\r現在のセッションにどのような Cookie があるかを確認したいだけの場合は、それらを直接表示できます。\n1 playwright-cli cookies このコマンドは、現在のコンテキスト内の Cookie をリストします。ログイン状態が存在するかどうか、Cookie が正常に書き込まれたかどうかを確認するのに適しています。\n04 クッキーを設定する\rすでに Cookie データがある場合は、直接書き込むこともできます。\n1 playwright-cli cookies set \u0026#39;[{\u0026#34;name\u0026#34;:\u0026#34;session\u0026#34;,\u0026#34;value\u0026#34;:\u0026#34;abc\u0026#34;,\u0026#34;domain\u0026#34;:\u0026#34;example.com\u0026#34;,\u0026#34;path\u0026#34;:\u0026#34;/\u0026#34;}]\u0026#39; この使用法は、認証のデバッグ、特定のセッションの再現、またはスクリプトの前に Cookie 条件を手動で挿入する場合に適しています。\n05 ローカルストレージの読み取り\r一部のサイトのログイン ステータスまたはフロントエンド ステータスは、Cookie だけでなく localStorage にも保存されます。\n1 playwright-cli local-storage このコマンドは、現在のページの localStorage コンテンツを表示するために使用されます。この手順は、「ログインしているように見えますが、ページの動作が間違っている」というトラブルシューティングを行う場合に役立ちます。\n06 ローカルストレージへの書き込み\rフロントエンドのステータスをシミュレートする必要がある場合は、それを直接設定することもできます。\n1 playwright-cli local-storage set token abc123 指定されたキー値を localStorage に書き込みます。一般的な用途は、トークン、基本設定、または一部のフロントエンド スイッチを挿入することです。\n07 セッションストレージの読み取り\rsessionStorage は、現在のセッションの一時的なステータスを表示するのに適しています。\n1 playwright-cli session-storage このコマンドは、現在のページの sessionStorage を出力します。特定のページ ロジックがワンタイム セッション データに依存している場合は、ここから確認できます。\n08 セッションストレージへの書き込み\r必要に応じて、sessionStorage を手動で設定することもできます。\n1 playwright-cli session-storage set key value これは、一時的な状態に依存する特定のページ動作を再現したり、初期化ステップに必要なフィールドを入力したりするのに適しています。\n09 IndexedDB の表示\rより重い Web アプリケーションの場合、本当に重要なデータは IndexedDB にある可能性があります。\n1 playwright-cli indexed-db このコマンドは、現在のページの IndexedDB データを表示するために使用されます。複雑な単一ページ アプリケーション、オフライン キャッシュ、またはローカル データベース スタイルの状態に遭遇した場合は、最初にここを確認できます。\n10 最も実用的なワークフローの 1 つ\rログイン状態を安定して再利用したいだけの場合、最も単純なプロセスは通常次のようになります。\nまずサイトを開いて手動でログインを完了します。 次のコマンドを実行してステータスを保存します。 1 playwright-cli storage-state save auth.json 後続の実行中に直接ロードします。 1 playwright-cli --storage-state auth.json ロード後もページに異常がある場合は、引き続き次の確認を行ってください。\nplaywright-cli cookies playwright-cli local-storage playwright-cli session-storage playwright-cli indexed-db このシーケンスで「状態が完全に復元されていない」という問題のほとんどはすでにカバーできます。\n11 使用上の注意点\r注目すべき点は次の 3 つです。\nstorage state ファイルは本質的に機密データであり、ログイン Cookie またはトークンが含まれる場合があります。安易に倉庫に提出しないでください。 単に Cookie を復元するだけでは必ずしも十分ではなく、多くの最新のサイトは localStorage、sessionStorage、または IndexedDB にも依存しています。 ステータス ファイルは永続的に有効ではないため、通常、Cookie の有効期限が切れた後、アカウントが変更された後、または環境が切り替わった後に再生成する必要があります。 12 簡単なまとめ\r一文しか覚えていない場合:\n**Playwright CLI の storage state は、ブラウザの現在の状態を保存し、後続のタスクで引き続き使用します。 **\n実際のトラブルシューティングでは、最も一般的に使用されるコマンドのセットは次のとおりです。\n1 2 3 4 5 6 playwright-cli storage-state save auth.json playwright-cli --storage-state auth.json playwright-cli cookies playwright-cli local-storage playwright-cli session-storage playwright-cli indexed-db 最初に保存してからロードします。そうでない場合は、Cookie とさまざまなローカル ストレージ層を確認してください。これは基本的に、このリファレンス ドキュメントの最も実践的な部分です。\n参考リンク\rPlaywright CLI ストレージ状態リファレンス ドキュメント: https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/storage-state.md Playwright CLI プロジェクトのホームページ: https://github.com/microsoft/playwright-cli ","date":"2026-04-14T22:19:55+08:00","permalink":"https://www.knightli.com/ja/2026/04/14/playwright-cli-storage-state-commands/","title":"Playwright CLI ストレージ状態の使用法: ログイン状態の保存、Cookie とローカル ストレージの読み取り"},{"content":"最近オープンソースの AI エージェント ツールに注目している場合、HKUDS/OpenHarness は注目に値する新しいプロジェクトです。これは単なる「チャット シェル」ではなく、実行可能、スケーラブル、管理可能なエージェント インフラストラクチャをオープン ソースの エージェント ハーネスに分離します。\n公式 README によると、OpenHarness は主に、ツールの呼び出し、スキルの読み込み、メモリ メカニズム、権限管理、マルチ エージェントの調整など、軽量のエージェントの基本機能のセットを提供します。およびそれに付随する ohmo は、このインフラストラクチャ上に構築されたパーソナル AI アシスタント アプリケーションです。\n01 オープンハーネスとは何ですか？\rOpenHarness は、「大きなモデルに手、足、メモリ、境界をインストールする」ランタイム層として理解できます。\n大規模なモデル自体は推論と生成に優れていますが、それを本当に長期間動作できるエージェントにしたい場合は、通常、次の周辺機能が必要です。\nテキストを出力するだけでなくツールを調整する ファイルの読み取りと書き込み、コマンドの実行、検索機能と Web 機能へのアクセス 長時間のセッションでもコンテキストとメモリを保持 危険な操作に対する権限の制御 大きなタスクを複数のサブエージェントに分割して並列処理する OpenHarness の目標は、この「モデル周辺のエンジニアリング層」を、明確でオープンソースでチェック可能な Python 実装に変えることです。これは、特定のモデルや特定のチャット インターフェイスのみを強調するのではなく、エージェントの操作ベースに似ています。\n02 本プロジェクトの基本機能\r現在の GitHub ホームページと README から判断すると、OpenHarness のコア機能は主に次の領域に集中しています。\n1. Agent Loop\rこれは、エージェントが継続的に動作できるコア実行ループです。公式ハイライトは次のとおりです。\nストリーミングツール呼び出しループ API の再試行と指数バックオフ ツールの並列実行 トークンの統計とコストの追跡 この部分の重要性は、エージェントが単なる「1 つの質問と 1 つの回答」ではなく、継続的に観察し、考え、ツールを呼び出し、結果を読み取り、タスクの次のステップに進むことができることです。\n2. ツール、スキル、プラグインシステム\rOpenHarness により、ツール層が比較的完全になりました。プロジェクトのホームページには、ファイル、シェル、検索、Web ページ、MCP などのツールが組み込まれており、オンデマンドでの Markdown スキル ファイルの読み込みをサポートしていると記載されています。\nその価値は「より多くのツール」だけではありませんが、さらに重要なのは、その組み合わせ方法が比較的オープンであることです。\n組み込みツールを直接使用可能 スキルはタスクごとにロード可能 フック、スキル、エージェントはプラグインを通じて拡張可能 anthropics/skills および関連プラグイン エコロジーと互換性があります このレイヤーは、毎回プロンプトによる一時的な説明に依存するのではなく、特定の固定プロセスを再利用可能な機能にまとめたい場合に役立ちます。\n3. コンテキストと記憶\rこの部分は OpenHarness の重要な差別化ポイントです。公式キーワードには次のようなものがあります。\nCLAUDE.md の検出と挿入 自動コンテキスト圧縮 MEMORY.md 永続メモリ セッションの回復と履歴の継続 これは、現在のラウンドの入力を処理するだけでなく、「プロジェクトのコミットメント」、「過去のタスク」、および「長期的な設定」を保持しようとすることを意味し、エージェントを毎回最初から開始するのではなく、継続的な作業により適したものにします。\n4. 当局のガバナンスとセキュリティ境界\rエージェントが実際にファイル システム、端末、ネットワークに入った後は、ガバナンスが非常に重要になります。 OpenHarness はこのセクションで次のことを提供します。\nマルチレベル権限モード パスとコマンドベースのルール制御 PreToolUse / PostToolUse hooks インタラクティブな承認ポップアップウィンドウ 簡単に言うと、エージェントが「できること」だけでなく、「直接実行できることと、最初に確認しなければならないこと」を考慮します。\n5. マルチエージェントの調整\rOpenHarness は、処理のためにタスクをサブエージェントにオフロードすることもサポートしています。現在の公開情報で言及されている機能には次のものが含まれます。\nサブエージェントの作成と委任 チーム登録とタスク管理 バックグラウンドタスクのライフサイクル管理 複雑なタスクの場合、これは、1 つのエージェントに依存して逐次的に進めるだけでなく、並行して共同作業を試みることもできることを意味します。\n6. マルチプロバイダーのワークフロー\rOpenHarness は現在、プロバイダーを単なる基盤となる API 名とは見なさず、それをワークフロー + プロファイルに抽象化します。 README によると、現在サポートされている指示は次のとおりです。\nClaude / Anthropic-compatible OpenAI-compatible Codex Subscription GitHub Copilot Moonshot (Kimi)、GLM、MiniMax、およびその他の互換性のあるバックエンド これにより、特定のサービス プロバイダーに束縛されるのではなく、「マルチモデル、マルチエントリー」エージェント実行フレームワークに似たものになります。\n7. React TUI と非対話型モード\rOpenHarness にはターミナルの対話型インターフェイスが付属しており、oh を実行した後に React/Ink TUI に入ることができます。公式の README には、以下をサポートしていると記載されています。\nコマンドセレクター 許可の確認 機種切り替え プロバイダースイッチ セッションの再開 対話型インターフェイスに入りたくない場合は、結果を標準出力、JSON、またはストリーミング JSON に出力するなど、非対話モードで単一のタスクを直接実行することもできます。これは、スクリプト作成や自動化のシナリオに適しています。\n03 ohmoとは\rOpenHarness が基盤となるインフラストラクチャである場合、ohmo は、このインフラストラクチャ上に構築された「パーソナル エージェント アプリケーション」です。\nohmo の位置付けはプロジェクトのホームページで非常に明確です。これは通常のチャットボットではなく、長時間の会話でも機能し続けるパーソナル アシスタントです。公式説明には、Feishu、Slack、Telegram、Discord、その他のチャネルでユーザーと対話し、次のようなタスクを実行できると記載されています。\nフォークブランチ コードを書く テストの実行 PRを始める さらに、README では、ohmo は既存の Claude Code または Codex サブスクリプション上で実行でき、必ずしも新しい API キーの追加アプリケーションを必要としないことも強調しています。これらのサブスクリプション ツールをすでに使用しているユーザーにとって、これは比較的参入障壁が低いです。\n04 どんなシーンに適していますか？\rこのプロジェクトで現在公開されている機能から判断すると、OpenHarness は次のタイプの人々に適しています。\n本番レベルのエージェントがどのような基本モジュールで構成されているかを調べたいと思っています。 スケーラブルなオープンソースのエージェント オペレーティング レイヤーを自分で構築したい ツール、スキル、メモリ、権限、マルチエージェントの調整を同じフレームワークに組み込みたい 単一のモデルメーカーや単一の顧客フォームに束縛されたくない 既製のアーキテクチャに基づいた垂直分野のエージェントまたはパーソナルアシスタントであり続けたいですか? あなたの目標が単に「直接チャットできる完成したアシスタントを見つける」ことである場合、OpenHarness オントロジーは最も軽い選択肢ではないかもしれません。ただし、エージェントのインフラストラクチャ、エンジニアリングの制御性、およびその後の拡張にもっと関心がある場合は、このプロジェクトを検討する価値があります。\n05 位置付けをすぐに理解する\r一文の要約:\n**OpenHarness は、大規模なモデルを実際にタスクを実行できるエージェントに変換する責任を負い、ohmo は、この一連の機能を、長期間使用できるパーソナル アシスタントにパッケージ化する責任があります。 **\n2 つのレイヤーに分割して確認することもできます。\nOpenHarness: オープンソースの Agent Harness、本質はインフラストラクチャです ohmo: このインフラストラクチャ上に構築されたパーソナル エージェント アプリ 2026 年 4 月 12 日の時点で、プロジェクトの GitHub ホームページには、更新が v0.1.6 (2026 年 4 月 10 日) に進み、引き続き自動コンテキスト圧縮、MCP 転送機能、React TUI、およびマルチエージェント実行の安定性に重点が置かれていることが示されています。これは、まだ急速な進化段階にあることを示していますが、方向性はすでに非常に明確です。\n参考リンク\rGitHub プロジェクトのホームページ: https://github.com/HKUDS/OpenHarness 英語の README: https://github.com/HKUDS/OpenHarness/blob/main/README.md 中国語の README: https://github.com/HKUDS/OpenHarness/blob/main/README.zh-CN.md ","date":"2026-04-12T23:45:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/12/openharness-basic-functions/","title":"OpenHarness とは: このオープンソースの Agent Harness では何ができるのですか?"},{"content":"現在、ブラウザ自動化に Claude Code、GitHub Copilot、またはその他のコーディング エージェントを使用している場合、microsoft/playwright-cli は注目に値する新しいツールです。これは、「コマンドを手動で入力するために使用される」従来の意味でのブラウザ ガジェットではなく、エージェントをコーディングするための Playwright CLI であり、トークン オーバーヘッドの低減、軽量のコマンド インターフェイス、およびスキル ワークフローとの統合を重視しています。\n公式 README から判断すると、Playwright CLI の核となる考え方は非常に明確です。モデル コンテキストに多数のツール スキーマとページ構造を詰め込む MCP と比較して、CLI コマンド方式はよりコンパクトで、大規模なコード ベース、テスト タスク、ブラウザ自動化の間を行き来するエージェント ワークフローにより適しています。\n01 Playwright CLIとは何ですか?\rplaywright-cli は、Microsoft がオープンソース化した Playwright コマンド ライン ツールです。公式説明は「一般的な Playwright アクション用の CLI」です。主に次のことを実現するために使用されます。\nページを開いてブラウザを起動します Playwright コードを記録して生成する ページのスナップショットを取得し、要素の参照を取得します スクリーンショット、PDF のエクスポート コーディングエージェントと連携して自動テストとWebページ運用を行います。 現在の GitHub README では、これを非常に明確に位置づけています。コーディング エージェントを使用している場合は、Playwright MCP よりも CLI の方が適していることがよくあります。永続的な状態、豊富なイントロスペクション、長いエージェント ループが必要な場合でも、MCP には価値があります。\n言い換えれば、Playwright CLI は、人間のエンジニアが Web ページを手動でクリックするための単なるツールではなく、「AI コーディング アシスタントのためのブラウザ自動化インターフェイス」に近いものです。\n02 そのメリットは何ですか?\r1. エージェントのワークフローにさらに適した\r公式READMEには、最初の利点がToken-efficientとして直接書かれています。データのページ全体を LLM コンテキストに強制的に組み込むのではなく、エージェントはより短く、より特殊なコマンドを通じてブラウザを操作できるようになります。\nこれはエージェントのコーディングにとって重要です。実際のプロジェクトでは、エージェントはブラウザを実行するだけでなく、コードの読み取り、ファイルの変更、テストの実行、ログの読み取りも行うためです。ブラウザ ツール自体が非常に「コンテキストを食べる」場合、全体の効率が大幅に低下します。\n2. スキルを使って作業する能力\rREADME では特に playwright-cli install --skills を強調しています。これは、公式がこれを単なるシェルツールとして捉えておらず、Claude Code や GitHub Copilot などのエージェントが直接利用できるスキルの入り口として設計していることを示しています。\nワークフロー自体がスキルに基づいて構築されている場合は、Playwright CLI への接続がより自然になります。\n3. セッション管理が比較的完了している\rPlaywright CLI はセッションをサポートします。デフォルトでは、ブラウザ プロファイルはメモリに保存され、同じセッション内の Cookie とストレージは複数の CLI 呼び出し間で保持されます。 --persistent が追加された場合、プロファイルをディスクにドロップし、ブラウザを再起動しても引き続き使用することもできます。\nこれにより、「コマンド 1 つでブラウザを開いて実行後に​​破棄する」というおもちゃのツールよりも実用的となり、継続的なデバッグやエージェントの長時間プロセスの実行にも適しています。\n4. 視覚監視パネルが付属しています\rplaywright-cli show は README に含まれており、ダッシュボードを開いて実行中のすべてのブラウザー セッションを監視および制御するために使用されます。これは、ただやみくもに実行するのではなく、いつでも引き継ぎ、監視、トラブルシューティングを行うことができるため、エージェントがバックグラウンドで自動化されたタスクを実行するシナリオで役立ちます。\n03 設置および環境要件\r現在の GitHub README によると、Playwright CLI の基本要件は次のとおりです。\nNode.js 18 以降 Claude Code、GitHub Copilot、またはその他のコーディング エージェント インストールコマンドは以下のとおりです。\n1 2 npm install -g @playwright/cli@latest playwright-cli --help ここには特に注意しなければならない非常に簡単な落とし穴があります。\n現在推奨されている公式インストールは @playwright/cli です。 これを、npm 上の歴史的で非推奨となった古いパッケージ playwright-cli と混同しないでください。 つまり、実際にインストールする必要があるのは、古い時代からの同名の履歴パッケージではなく、スコープ指定されたパッケージです。\n04 始め方\r1. スキルをインストールする\rコーディング エージェントに Playwright CLI を直接使用させたい場合は、最初にスキルをインストールすることが公式推奨されています。\n1 playwright-cli install --skills README には、Claude Code や GitHub Copilot などのツールがローカルにインストールされたスキルを使用することが明確に記載されています。\n2. エージェントに CLI を直接呼び出させる\r最初にスキルを処理したくない場合は、エージェントに CLI ヘルプ情報を直接読み取らせることもできます。\n1 2 Test the \u0026#34;add todo\u0026#34; flow on https://demo.playwright.dev/todomvc using playwright-cli. Check playwright-cli --help for available commands. 正式にはこの方法を「スキルレス操作」といいます。これは、スキルがプリインストールされていない場合でも、CLI 自己記述機能を通じてエージェントを駆動できることを意味します。\n3. 最小限の工程を手動で体験\rREADME には、開始するのに非常に適した一連の TodoMVC サンプルが含まれています。\n1 2 3 4 5 6 7 8 playwright-cli open https://demo.playwright.dev/todomvc/ --headed playwright-cli type \u0026#34;Buy groceries\u0026#34; playwright-cli press Enter playwright-cli type \u0026#34;Water flowers\u0026#34; playwright-cli press Enter playwright-cli check e21 playwright-cli check e35 playwright-cli screenshot このコマンド セットの価値は、Playwright CLI がどのように対話するかをすぐに理解できることです。\nopen はページを開く責任があります type および press は入力を担当します check 要素参照を使用したチェックボックスの操作 screenshot 結果を保存 05 --headed、セッションおよびモニタリングパネル\r--headed\rPlaywright CLI はデフォルトではヘッドレスです。ブラウザ ウィンドウを直接表示したい場合は、--headed を open に明示的に追加する必要があります。\n1 playwright-cli open https://playwright.dev --headed これは、セレクター、ログイン プロセス、検証コードの前後のインタラクティブな観察のデバッグに便利です。\nsession\r公式 README ではセッションの使用法が強調されています。異なるセッションを使用して、異なるプロジェクトまたは Web サイトを分離できます。\n1 2 3 playwright-cli open https://playwright.dev playwright-cli -s=example open https://example.com --persistent playwright-cli list エージェントを長時間動作させたい場合は、環境変数を直接指定することもできます。\n1 PLAYWRIGHT_CLI_SESSION=todo-app claude . 一般的に使用されるセッション管理コマンドには次のものがあります。\n1 2 3 playwright-cli list playwright-cli close-all playwright-cli kill-all で：\nlist はすべてのセッションをリストするために使用されます close-all は、すべてのブラウザを通常どおり閉じるために使用されます。 kill-all は、すべてのブラウザ プロセスを強制的に終了するために使用されます。 監視パネル\rブラウザでエージェントが現在何を行っているかを確認したい場合は、次のコマンドを実行できます。\n1 playwright-cli show README によると、このダッシュボードには主に 2 つのビューがあります。\nセッション グリッド: すべてのアクティブなセッションをワークスペースごとに表示し、ライブ ビュー、URL、ページ タイトルを表示します。 セッションの詳細: 単一セッションのリアルタイム インターフェイスを表示し、マウスとキーボードを引き継ぐこともできます これにより、Playwright CLI は「コマンドラインが利用可能」になるだけでなく、比較的成熟した可観測性も備えます。\n06 最初に覚えるべき一般的なコマンドはどれですか?\rPlaywright CLI を初めて使用する場合は、最初からすべてのコマンドを覚える必要はありません。最初に次の中心点を覚えておくだけで十分です。\nページとインタラクション\r1 2 3 4 5 6 7 playwright-cli open [url] playwright-cli goto \u0026lt;url\u0026gt; playwright-cli click \u0026lt;ref\u0026gt; playwright-cli fill \u0026lt;ref\u0026gt; \u0026lt;text\u0026gt; playwright-cli type \u0026lt;text\u0026gt; playwright-cli hover \u0026lt;ref\u0026gt; playwright-cli press \u0026lt;key\u0026gt; ページ構造を取得する\r1 2 3 4 playwright-cli snapshot playwright-cli snapshot \u0026lt;ref\u0026gt; playwright-cli snapshot --depth=N playwright-cli eval \u0026lt;func\u0026gt; [ref] 後続の多くの操作は要素参照 ref に依存するため、snapshot は重要です。通常は、最初にスナップショットを取得し、次に返された要素番号を使用してクリック、入力、チェック、またはスクリーンショットの取得を行います。\n出力結果\r1 2 playwright-cli screenshot playwright-cli pdf タブページ\r1 2 3 4 playwright-cli tab-list playwright-cli tab-new [url] playwright-cli tab-close [index] playwright-cli tab-select \u0026lt;index\u0026gt; 07 どんな人に向いていますか？\r次のいずれかのシナリオに該当する場合は、Playwright CLI を試してみる価値があります。\nE2E テストに Claude Code、Copilot、またはその他のコーディング エージェントを使用している ブラウザ自動化インターフェイスをより軽量にしたいが、コンテキストに多くのページ構造を詰め込みたくない場合 複数のコマンド間で同じブラウザ セッションを維持したい場合 エージェントが Web ページ タスクを自動的に実行するとき、いつでも監視パネルを開いて進行状況を観察したいと考えています。 「ブラウザの自動化がコーディング エージェントとどのように効果的に連携できるか」が仕事の焦点である場合、Playwright CLI は従来の人による手動のデバッグ方法よりも便利である可能性があります。\n参考リンク\rGitHub: https://github.com/microsoft/playwright-cli README: https://github.com/microsoft/playwright-cli/blob/main/README.md ","date":"2026-04-12T14:36:58+08:00","permalink":"https://www.knightli.com/ja/2026/04/12/playwright-cli-getting-started/","title":"Playwright CLI の入門: インストール、スキル、セッション管理、および一般的なコマンド"},{"content":"最近オープンソース AI エージェントに注目している場合、Hermes Agent は注目に値する新しいプロジェクトです。ヌース・リサーチ社によって発売されました。その中心的なセールスポイントは、「別のチャット シェルを作成する」ことではなく、長期記憶、スキルの蓄積、コンテキスト ファイル、MCP 拡張機能、メッセージ ゲートウェイ、およびサブエージェントの並列処理の機能を統合エージェント実行環境に統合しようとすることです。\n公式 README から判断すると、Hermes Agent の目標は非常に明確です。ローカル CLI アシスタントのように、またはクラウドに常駐するパーソナル アシスタントのようにターミナル内で動作し、Telegram、Discord、Slack、WhatsApp、Signal などのチャネルを通じて継続的に話しかけることができます。この位置付けは、「コード アシスタント」、「自動化アシスタント」、「パーソナル AI ワークベンチ」を 1 つのシステムに組み合わせたいユーザーにとって、非常に魅力的です。\n01 エルメス代理店紹介\rHermes Agent は、Nous Research が開発したオープンソースの自己改善型 AI エージェントです。 Nous Portal、OpenRouter、OpenAI、カスタム OpenAI 互換エンドポイントなど、複数のモデル プロバイダーをサポートします。また、ローカル ターミナル、Docker、SSH、Daytona、Modal などのさまざまな実行バックエンドでの実行もサポートされます。\n多くの「ツールを呼び出すことができるチャットボット」との最大の違いは、Hermes は 1 つのセッションでのツール呼び出しだけを重視するのではなく、セッション全体での継続的な機能構築を重視していることです。公式ドキュメントでは、このアイデアをいくつかの部分に分割しています。\n永続メモリ: MEMORY.md および USER.md を通じて、環境、プロジェクト、およびユーザー設定に関する重要な情報を保存します。 スキル システム: 複雑なタスクで学習したプロセスをスキルにまとめ、オンデマンドでロードします。 コンテキスト ファイル: AGENTS.md、SOUL.md、.cursorrules およびその他のファイルを自動的に読み取り、プロジェクト規約をセッションに直接挿入します。 MCP の統合: MCP 互換のツール サーバーに接続して、データベース、GitHub、ファイル システム、クロールなどの機能を拡張できます。 メッセージ ゲートウェイ: CLI に加えて、Telegram、Discord、Slack、WhatsApp、Signal、電子メール、その他のポータル経由でも使用できます。 一言で要約すると、Hermes Agent は「メモリ、スキル、スケーラビリティ、およびマルチエンド アクセスを備えたユニバーサル エージェント操作層」に似ています。\n02 そのメリットは何ですか?\r1. CLI ワークフローとメッセージング ワークフローの両方をカバーする\rエージェントプロジェクトの多くは「端末内開発アシスタント」か「チャットプラットフォームロボット」のどちらかです。エルメスがやりたいのは、これら 2 つを融合することです。ターミナルで hermes を直接実行することも、ゲートウェイを起動して Telegram または Discord から同じアシスタントを継続することもできます。\nこのデザインの良いところは、エルメスが「コンピューターの前に座っているときにだけ使える」ということに限定されていないことです。クラウドまたは VPS に導入すると、常にオンラインのパーソナル AI アシスタントになります。\n2.「長期使用」をより徹底して考える\rヘルメスは単にチャットやツールの調整を行うだけではなく、長期的な蓄積も重視しています。\n無限のヒープ コンテキストではなく、制限された永続メモリ。 成功したプロセスを保存して再利用できるスキル システムがあります。 過去のセッションを検索し、セッション間の呼び出しを実行する機能。 プロジェクト内のコンテキスト ファイルを読み取ることができるため、プロジェクトの背景を毎回繰り返し説明する必要性が軽減されます。 これは、固定されたコード ベース、固定されたワークフロー、固定されたチーム基準で繰り返し作業することが多いユーザーにとって重要です。これは、エージェントが「今回はあなたのために何かをしてくれる」だけではなく、徐々にあなたの環境をよりよく理解するようになるということを意味します。\n3. MCP サポートにより拡張性が非常に強力になります\rhermes の公式ドキュメントでは、MCP を明確にサポートしており、stdio と HTTP という 2 つのアクセス方法について説明しています。言い換えれば、外部システムにすでに MCP サーバーがある限り、Hermes は理論的には低コストでそれにアクセスできます。\nこれは、単一システムに対して毎回個別のプラグインを作成するよりも柔軟です。 MCP エコシステムに多数のツールを蓄積している人にとって、Hermes へのアクセス コストははるかに低くなります。\n4. OpenClaw ユーザーに優しい\rこれはとても興味深いですね。 Hermes README には hermes claw migrate が直接提供されており、構成、メモリ、スキル、API キー、メッセージング プラットフォームの設定などを OpenClaw からインポートできることが記載されています。\nこれは、既存のエコロジーを完全に無視して車輪を再発明しているわけではなく、一部の OpenClaw ユーザーを潜在的な移行ターゲットとして明確にみなしていることを示しています。\n03 すぐに始める方法\r公式に推奨されている Hermes Agent のインストール方法は非常に簡単です。\n1 curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash 公式の手順では、Linux、macOS、WSL2、Android の Termux がサポートされています。 README には、ネイティブ Windows はまだサポートされていないため、Windows ユーザーには WSL2 を使用することが推奨されていることが明記されていることに注意してください。\nインストールが完了したら、通常は最初にシェルを更新します。\n1 source ~/.bashrc その後、直接開始できます。\n1 hermes 段階的に完全な初期化を完了したい場合、最も心配のないコマンドは次のとおりです。\n1 hermes setup 公式ドキュメントと README によると、初めて開始するには次の手順に従うことができます。\nhermes setup を実行して、基本構成を完了します。 hermes model を使用して、モデルプロバイダーとモデルを選択します。 hermes tools スイッチにはツールセットが必要です。 hermes を直接実行して対話型 CLI に入ります。 Telegram や Discord などのチャネルに接続する場合は、hermes gateway の構成を続けます。 OpenClaw ユーザーの場合は、移行コマンドを確認することもできます。\n1 hermes claw migrate --dry-run 正式にインポートするかどうかを決定する前に、移行可能なコンテンツをプレビューします。\n04 と OpenClaw はどうですか?\r公式ドキュメントや README から判断すると、Hermes Agent と OpenClaw は単に「誰が誰を置き換えるか」というだけではなく、位置づけにおいては明らかに重複していますが、焦点は異なります。\nヘルメスエージェントとはどのようなものですか?\rエルメスはどちらかというとエージェントコアとワークフローシステムに重点を置いた製品です。それが強調していることは次のとおりです。\nCLI の経験 記憶とスキルの蓄積 プロジェクトコンテキストファイル MCP拡張子 サブエージェントの並列処理 ローカル、コンテナ、リモート、サーバーレス環境間で実行バックエンドを切り替える あなたの主な要求が「エージェントにプロジェクトをよりよく理解させ、継続的な再利用機能を向上させ、MCP と開発ワークフローへの接続を容易にする」ことである場合、Hermes の方向性はより便利になります。\nOpenClaw とはどのようなものですか?\rOpenClaw は、パーソナル AI アシスタントとメッセージング ゲートウェイを中心としたプラットフォームです。それは次のように強調します。\nメッセージチャネルへの非常に豊富なアクセス ゲートウェイを実行する常駐者 ブラウザーでの UI の制御 デバイスのペアリング、リモートアクセス、ステータス管理 音声、モバイル、キャンバスなどの強力なアシスタント形式。 「さまざまなチャット チャネルやデバイス上でパーソナル AI アシスタントを安定させる」ことが主なニーズであり、コントロール パネルを使用して均一に管理したい場合は、OpenClaw の製品感が強くなります。\nより現実的な選択の提案\rこの 2 つは単純に次のように理解できます。\nヘルメスエージェント：「成長する総合エージェントのワークベンチ」 OpenClaw: 「マルチチャネル常駐パーソナル AI アシスタント プラットフォーム」のようなもの もちろん、この違いは絶対的なものではなく、双方とも機能を拡張し続けており、Hermes は OpenClaw からの移行パスも提供しています。しかし、少なくとも現在の公開情報から判断すると、Hermes は「メモリ、スキル、コンテキスト、MCP、開発ワークフロー」の分野でより顕著です。 OpenClaw は、「ゲートウェイ、マルチチャネル、コントロール UI、デバイス アクセス」の分野でより成熟しています。\n05 どんな人に試してほしいの？\rあなたが次のカテゴリーに属する人であれば、Hermes Agent を最初に試してみる価値があります。\nあなたはターミナルで AI ツールを広範囲に使用しており、エージェントがコード ベースとプロジェクト ルールをよりよく理解できるようになることを期待しています。 AGENTS.md、スキル、記憶、MCP 能力を組み合わせたいと考えています。 単一のモデル ベンダーに縛られることなく、柔軟にプロバイダーを切り替えられるようにしたいと考えています。 以前に OpenClaw を使用していましたが、今度はよりエージェント指向のワークフローの方向を試したいと考えています。 より多くのモバイルリーチ、さまざまな IM プラットフォームへのアクセス、ブラウザ コンソール、および「常時接続のパーソナル アシスタントの感覚」を重視する場合は、OpenClaw が依然として魅力的です。\n参考リンク\rHermes Agent GitHub: https://github.com/NousResearch/hermes-agent ヘルメスエージェントドキュメント: https://hermes-agent.nousresearch.com/docs/ Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/ OpenClaw GitHub: https://github.com/openclaw/openclaw OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui ","date":"2026-04-12T14:07:58+08:00","permalink":"https://www.knightli.com/ja/2026/04/12/hermes-agent-intro-guide-vs-openclaw/","title":"Hermes Agent とは: 概要、利点、クイック スタート、OpenClaw との比較"},{"content":"大規模モデルの長期記憶は常に問題でした。コンテキストが蓄積すればするほど、情報が混乱しやすくなります。知的なエージェントはすべてを覚えているように見えますが、実際には、何が重要で、何が忘れるべきかを判断することがますます困難になります。\n4 月 5 日、OpenClaw は新バージョンの実験機能「Dreaming」を開始しました。これは派手な名前ではなく、人間の睡眠プロセスを模倣する一連のバックグラウンド記憶構成メカニズムです。目標は非常に単純で、知的エージェントが目覚めた後により正確に記憶できるようにすることです。\n01 睡眠アルゴリズム：記憶整理を3段階に分ける\r夢を見ることは単にインデックスを作成することではなく、人間の睡眠中のさまざまな機能に対応して、記憶を 3 つの論理的な段階に編成します。\n浅い睡眠: システムは最初に最近の会話と思い出の記録をスキャンし、重複の削除と予備的なスクリーニングを実行して、候補コンテンツを生成します。この段階では、一時的な保存のみが実行され、コア メモリ ファイル MEMORY.md は直接変更されません。\nディープ スリープ: システムは、ルールに従って価値の高い情報のフィルタリングを開始します。最低の評価、最低のリコール数、最低の固有クエリ数を満たす情報のみが次のステップに進みます。書き込む前に、最新のログが再度比較され、古い内容が削除されます。最後に、結果は MEMORY.md に追加され、ディープ スリープの概要が DREAMS.md に残ります。\n急速眼球運動段階 (REM): 記憶が定着した後、システムはさらに短期の行動追跡を分析し、異なる情報間の潜在的なつながりを探し、パターンの要約と反映内容を生成します。この部分は、エージェントが複雑なタスクを処理するときに全体の状況をより簡単に把握できるように、専用の REM ブロックに書き込まれます。\nマシン自体の記憶整理メカニズムに加えて、Dreaming は人間の読書により適した「夢日記」も生成します。素材がある程度溜まるとバックグラウンドサブエージェントがデフォルトモデルを呼び出してDREAMS.mdに簡潔な記述を追加します。\n02 採点の仕組み：何を残し、何を忘れるべきかを決める\r夢を見るための鍵は「整理する」だけではなく「ふるい分ける」ことです。 OpenClaw は、大規模なフルスケール ストレージを使用し続ける代わりに、重み付けされたスコアリング メカニズムを使用して、どの情報を長期記憶に入れる価値があるかを判断します。\nこのメカニズムは主に次の 6 つの次元に注目します。\n関連性の重み (30%): 情報が検索されたときに役立つかどうかを測定します。 頻度重み付け (24%): ある情報が繰り返し言及された回数をカウントします。 クエリの多様性 (15%): さまざまな質問やシナリオにわたってそれが現れるかどうかを確認します。 適時性の重み (15%): より新しい情報に高い優先度を与えます。 統合の重み (10%): 情報が複数の日に渡って安定して表示されるかどうかを確認します。 コンセプトの豊富さ (6%): その背後にある関連コンセプトが十分に充実しているかどうかを判断します。 これは、システムが長期記憶にすべてを詰め込むのではなく、繰り返し表示され、問題を解決し、時代を超えた情報を保持することを優先することを意味します。\n03 なぜクロードの「夢」の考えを人々に思い出させるのでしょうか?\r一部の開発者は、OpenClaw の Dreaming アップグレードの背後にあるアイデアが、Claude Code の漏洩コードに登場した KAIROS 自動ドリーミング メカニズムと非常によく似ていると信じています。以前は、MEMORY.md 全体の読み取りと書き込みを繰り返す方法では、後の段階でメモリ システムがますます肥大化する可能性がありました。一方、Dreaming はプロセスを浅い睡眠の統合、深い睡眠の固化、REM の関連付けに分割します。ロジックは明らかにより明確で、「最初に組織化し、次に沈殿させ、次に精製する」というアイデアに近くなります。\n神経科学の観点からこのデザインを肯定する人もいます。なぜなら、夢、浅い睡眠、深い睡眠、レムの概念は単なるランダムな名前ではなく、記憶を定着させるために明らかに人間の睡眠モデルから借用したものだからです。\nOpenClaw の既存の IDENTITY.md、USER.md、HEARTBEAT.md はすでにエージェントの個性、ユーザー コンテキスト、実行継続性を提供していますが、DREAMS.md が追加するのは「どの記憶を保持するか」を指定する機能です。\n04 最も皮肉なシーン: 機械は夢を見ることを学ぶが、人間は眠れない\rDreaming の本当の価値は、AI にすべてを記憶させることではなく、短期記憶を見直し、基礎となるパターンを抽出し、ノイズをフィルターする方法を学習させることです。本当に役立つエージェントは、モバイル ハード ドライブのように丸暗記するのではなく、ユーザーの好み、目標、背景をますます理解する必要があります。\n工学的な観点から見ると、このメカニズムの最も注目すべき点は、それが神秘的ではないということです。これはブラック ボックス マジックではなく、ステージ、しきい値、反映、および忘却ルールを備えた一連のバックグラウンド プロセスです。この設計により、AI の記憶メカニズムが、単なる「コンテキストの無限のヒープ」ではなく、初めて「制御可能なシステム」のように見えます。\nしかし、それが全体を少し皮肉なものにしているのです。私たちは機械に人間のように夢を見る方法を教えるために多大なリソースを投資していますが、同時に多くの人々がこれらのますますスマート化するシステムに取って代わられるのではないかという恐怖で眠れなくなっています。\n","date":"2026-04-12T12:41:34+08:00","permalink":"https://www.knightli.com/ja/2026/04/12/openclaw-dreaming-machine-dreams-humans-lose-sleep/","title":"OpenClaw 脳に似た記憶アルゴリズム 夢を見る: 機械は夢を見始めるが、人間は不眠症になる"},{"content":"llama-quantize は、llama.cpp の量子化ツールで、高精度 GGUF モデルをより小さい量子化バージョンに変換するために使用されます。\n最も一般的な用途は、F32、BF16、FP16 などの高精度モデルを、ローカル操作に適した Q4_K_M、Q5_K_M、Q8_0 などの形式に変換することです。量子化後、モデルのサイズは大幅に小さくなり、通常は推論が速くなりますが、精度はある程度低下します。\n基本的な使い方\r一般的なプロセスでは、通常、最初に元のモデルを準備し、次にそれを GGUF に変換し、最後に定量化を実行します。\n1 2 3 4 5 6 7 8 # install Python dependencies python3 -m pip install -r requirements.txt # convert the model to ggml FP16 format python3 convert_hf_to_gguf.py ./models/mymodel/ # quantize the model to 4-bits (using Q4_K_M method) ./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M 量子化が完了したら、llama-cli を直接使用して新しい GGUF ファイルをロードできます。\n1 2 # start inference on a gguf model ./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p \u0026#34;You are a helpful assistant\u0026#34; 共通パラメータ\r--allow-requantize: すでに定量化されたモデルの再定量化が可能ですが、品質が大幅に低下する可能性があるため、通常は推奨されません。 --leave-output-tensor: 量子化せずに出力レイヤーを保持します。ボリュームは大きくなりますが、場合によっては品質が向上する場合があります。 --pure: 混合量子化をオフにして、より多くのテンソルが同じ量子化タイプを使用できるようにします。 --imatrix: 重要度マトリックスを使用して量子化効果を最適化します。通常は優先順位を付ける価値があります。 --keep-split: 単一ファイルにマージするのではなく、入力モデルのシャード構造を保持します。 単に始めたい場合は、最も現実的な出発点は次のとおりです。\n1 ./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M 定量化の選び方\rまず、さまざまな定量化レベルを「体積、速度、質量の間の交換」として理解することができます。\nQ8_0: サイズは大きくなりますが、一般に品質がより安定しています。 Q6_K / Q5_K_M: 共通のバランス型オプション Q4_K_M: 非常に一般的なデフォルト ファイル。通常、音量とエフェクトは比較的バランスが取れています。 Q3 / Q2: リソースが非常に不足しているが、品質の低下がより明らかになるシナリオに適しています。 与えられたデータ例から判断すると、通常、量子化レベルが低いほど、モデルは小さくなります。実際の推論では、精度が高いほど必ずしも高速であるとは限りません。そのため、通常、選択の焦点は「大きいほど良い」ではなく、「ハードウェア上で十分に安定しており、十分に経済的で、効果が許容範囲である」ことに重点を置きます。\n実践的なアドバイス\rQ4_K_M または Q5_K_M から優先順位を付ける 品質がより重要な場合は、Q6_K または Q8_0 にアップグレードしてください。 マシン リソースが不足している場合は、Q3 または Q2 を試してください。 異なる量子化バージョンを比較するには、常に同じバッチのテスト問題を使用することが最善です 一文の要約: llama-quantize の中心的な価値は、単にモデルを小さくすることではなく、GGUF モデルをローカル デバイス上で実行しやすくすることです。\n","date":"2026-04-12T09:42:36+08:00","permalink":"https://www.knightli.com/ja/2026/04/12/llama-quantize-gguf-guide/","title":"llama-quantize の使用方法: GGUF モデル量子化の概要"},{"content":"llama.cpp は、Hugging Face の GGUF モデルで直接使用できます。最初にファイルを手動でローカルにダウンロードする必要はありません。\nモデル ウェアハウス自体が GGUF ファイルを提供している場合は、次のようにコマンド ラインで -hf パラメーターを直接使用できます。\n1 llama-cli -hf ggml-org/gemma-3-1b-it-GGUF デフォルトでは、このパラメータは Hugging Face からモデルをダウンロードします。\nHugging Face API と互換性のある別のモデル ホスティング サービスを使用している場合は、環境変数 MODEL_ENDPOINT を通じてダウンロード エンドポイントを切り替えることもできます。\nllama.cpp は、GGUF 形式のみを直接使用できることに注意してください。\n他の形式でモデル ファイルを取得した場合は、まずウェアハウス内の convert_*.py スクリプトを使用して、それを GGUF に変換する必要があります。\nHugging Face は、llama.cpp に関連するいくつかのオンライン ツールも提供します。一般的な用途には次のようなものがあります。\nモデルを GGUF に変換します モデルを定量化し、サイズを縮小する LoRA アダプターを変換する GGUF メタデータをオンラインで編集する llama.cpp 推論サービスを直接ホストする 最も実用的な結論だけを覚えておきたい場合は、まず GGUF をすでに提供しているモデル ウェアハウスを探し、次に llama-cli -hf \u0026lt;user\u0026gt;/\u0026lt;model\u0026gt; を直接使用します。これが通常は最も簡単な方法です。\n","date":"2026-04-12T09:31:38+08:00","permalink":"https://www.knightli.com/ja/2026/04/12/llama-cpp-hugging-face-gguf-models/","title":"llama.cpp Hugging Face から GGUF モデルを取得する方法"},{"content":"現在の Codex アカウントの残高を確認したい場合は、ChatGPT の /backend-api/wham/usage インターフェイスを要求する小さなスクリプトを直接作成できます。\nこのタイプのスクリプトの考え方は非常にシンプルです。\nauth.json から tokens.access_token および tokens.account_id を読み取ります リクエスト https://chatgpt.com/backend-api/wham/usage リクエストヘッダーに Authorization: Bearer ... と ChatGPT-Account-Id を含めます 返された結果の 5 時間のウィンドウと週ごとのウィンドウ クォータを解析します。 やるべきことに適した\rこの方法は、ローカルですばやく確認するのに適しています。\n5 時間の割り当てはどれくらい残っていますか? 週の割り当てはどれくらい残っていますか? クォータはいつリセットされますか? 複数のアカウントをお持ちの場合は、スクリプトで account/*.auth.json を一括で読み込み、一律に集計表を出力することもできます。 auth.json ファイルは、現在ログインしている chatgpt アカウントに対応する ~/.codex/ ディレクトリにあります。\n最も重要なインプット\r通常、スクリプトは次の 2 つの資格情報のみに依存します。\naccess_token account_id これらは通常、ローカルの auth.json から入手できます。これら 2 つの値が有効である限り、リクエスト ヘッダーは次のように構成できます。\n1 2 3 4 5 6 7 8 headers = { \u0026#34;Authorization\u0026#34;: f\u0026#34;Bearer {auth_token}\u0026#34;, \u0026#34;Accept\u0026#34;: \u0026#34;application/json\u0026#34;, \u0026#34;ChatGPT-Account-Id\u0026#34;: auth_account_id, \u0026#34;Origin\u0026#34;: \u0026#34;https://chatgpt.com\u0026#34;, \u0026#34;Referer\u0026#34;: \u0026#34;https://chatgpt.com/\u0026#34;, \u0026#34;User-Agent\u0026#34;: \u0026#34;Mozilla/5.0\u0026#34;, } 返された結果の見方\rインターフェイスが戻った後は、次の 2 種類のウィンドウに焦点が当てられます。\nfive_hour weekly スクリプトはそれらを次の項目に整理できます。\n残高の割合 リセット時間 対応する時間ウィンドウの長さ インターフェイス フィールド名が異なる場合、バリアント primary_window、secondary_window、five_hour_limit、および weekly_limit とも互換性がある可能性があります。\nよくある質問\rスクリプトが 401 を返した場合、通常、access_token の有効期限が切れているか、無効であることを意味します。\n403 が返された場合は、通常、現在のアカウントにこのインターフェイスにアクセスする権限がないか、アカウントのステータスが異常であることを意味します。\n同じ応答内でフィールドの名前が一貫していない場合でも驚かないでください。実際の処理では、異なる命名方法を統一的にマッピングしてから出力するのがベストです。\n参考リンク\rcodex-auth-manager：https://github.com/RioArisk/codex-auth-manager コード\r1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 import argparse import base64 import json import os import sys from datetime import datetime, timedelta, timezone from pathlib import Path from typing import Any import requests UTC = timezone.utc CST = timezone(timedelta(hours=8), name=\u0026#34;CST\u0026#34;) JSONDict = dict[str, Any] def parse_args() -\u0026gt; argparse.Namespace: parser = argparse.ArgumentParser( description=\u0026#34;Query ChatGPT Codex usage from /backend-api/wham/usage.\u0026#34; ) parser.add_argument( \u0026#34;account_name\u0026#34;, nargs=\u0026#34;?\u0026#34;, help=\u0026#34;Account name used to load account/\u0026lt;account_name\u0026gt;.auth.json. If omitted, load all *.auth.json files in account/.\u0026#34;, ) parser.add_argument( \u0026#34;--account-dir\u0026#34;, default=\u0026#34;account\u0026#34;, help=\u0026#34;Directory containing \u0026lt;account_name\u0026gt;.auth.json files.\u0026#34;, ) parser.add_argument( \u0026#34;--chatgpt-url\u0026#34;, default=\u0026#34;https://chatgpt.com/backend-api/wham/usage\u0026#34;, help=\u0026#34;ChatGPT usage endpoint.\u0026#34;, ) parser.add_argument( \u0026#34;--raw-json\u0026#34;, action=\u0026#34;store_true\u0026#34;, help=\u0026#34;Print the full JSON response body.\u0026#34;, ) parser.add_argument( \u0026#34;--raw-headers\u0026#34;, action=\u0026#34;store_true\u0026#34;, help=\u0026#34;Print response headers.\u0026#34;, ) return parser.parse_args() def print_json(data: Any) -\u0026gt; None: print(json.dumps(data, indent=2, ensure_ascii=False)) def load_auth_json(path_str: str | Path | None) -\u0026gt; JSONDict | None: if not path_str: return None path = Path(path_str).expanduser() if not path.is_file(): return None try: return json.loads(path.read_text(encoding=\u0026#34;utf-8\u0026#34;)) except (OSError, json.JSONDecodeError): return None def get_nested_string(data: JSONDict | None, *keys: str) -\u0026gt; str | None: current: Any = data for key in keys: if not isinstance(current, dict): return None current = current.get(key) return current if isinstance(current, str) and current else None def format_dt(dt: datetime | None) -\u0026gt; str: if dt is None: return \u0026#34;-\u0026#34; return dt.astimezone(CST).strftime(\u0026#34;%Y-%m-%d %H:%M:%S %Z\u0026#34;) def format_cst(dt: datetime | None) -\u0026gt; str: return format_dt(dt) def epoch_ms_to_dt(value: Any) -\u0026gt; datetime | None: if value is None: return None try: raw = int(value) except (TypeError, ValueError): return None # Newer responses sometimes use epoch seconds, older ones use epoch milliseconds. timestamp = raw / 1000 if raw \u0026gt; 10**11 else raw return datetime.fromtimestamp(timestamp, tz=UTC) def first_dict(data: Any, *keys: str) -\u0026gt; JSONDict | None: for key in keys: value = data.get(key) if isinstance(data, dict) else None if isinstance(value, dict): return value return None def decode_jwt_exp(token: str) -\u0026gt; datetime | None: parts = token.split(\u0026#34;.\u0026#34;) if len(parts) != 3: return None try: payload = parts[1] payload += \u0026#34;=\u0026#34; * (-len(payload) % 4) data = json.loads(base64.urlsafe_b64decode(payload.encode(\u0026#34;ascii\u0026#34;))) exp = data.get(\u0026#34;exp\u0026#34;) if exp is None: return None return datetime.fromtimestamp(int(exp), tz=UTC) except (ValueError, TypeError, json.JSONDecodeError): return None def get_percent_left(value: JSONDict) -\u0026gt; float | int | None: percent_left = value.get(\u0026#34;percent_left\u0026#34;) if percent_left is None: percent_left = value.get(\u0026#34;remaining_percent\u0026#34;) if percent_left is not None: return percent_left used_percent = value.get(\u0026#34;used_percent\u0026#34;) try: if used_percent is not None: return max(0, 100 - float(used_percent)) except (TypeError, ValueError): return None return None def resolve_limit_window(value: JSONDict) -\u0026gt; JSONDict: if ( \u0026#34;reset_at\u0026#34; not in value and \u0026#34;reset_time_ms\u0026#34; not in value and isinstance(value.get(\u0026#34;primary_window\u0026#34;), dict) ): return value[\u0026#34;primary_window\u0026#34;] return value def parse_limit_entry(name: str, value: Any) -\u0026gt; JSONDict | None: if not isinstance(value, dict): return None value = resolve_limit_window(value) percent_left = get_percent_left(value) reset_time_ms = value.get(\u0026#34;reset_time_ms\u0026#34;) if reset_time_ms is None: reset_time_ms = value.get(\u0026#34;reset_at\u0026#34;) window_seconds = value.get(\u0026#34;limit_window_seconds\u0026#34;) return { \u0026#34;name\u0026#34;: name, \u0026#34;percent_left\u0026#34;: percent_left, \u0026#34;reset_time_ms\u0026#34;: reset_time_ms, \u0026#34;reset_at\u0026#34;: epoch_ms_to_dt(reset_time_ms), \u0026#34;limit_window_seconds\u0026#34;: window_seconds, } def infer_limit_name(window_seconds: Any) -\u0026gt; str | None: if not isinstance(window_seconds, (int, float)): return None if window_seconds \u0026lt;= 6 * 3600: return \u0026#34;five_hour\u0026#34; if window_seconds \u0026gt;= 6 * 24 * 3600: return \u0026#34;weekly\u0026#34; return None def relabel_rate_limits(primary: JSONDict | None, secondary: JSONDict | None) -\u0026gt; tuple[JSONDict | None, JSONDict | None]: for entry in (primary, secondary): if not entry: continue inferred_name = infer_limit_name(entry.get(\u0026#34;limit_window_seconds\u0026#34;)) if inferred_name: entry[\u0026#34;name\u0026#34;] = inferred_name if primary and secondary and primary.get(\u0026#34;name\u0026#34;) == secondary.get(\u0026#34;name\u0026#34;): if primary.get(\u0026#34;name\u0026#34;) == \u0026#34;weekly\u0026#34;: primary[\u0026#34;name\u0026#34;] = \u0026#34;five_hour\u0026#34; else: secondary[\u0026#34;name\u0026#34;] = \u0026#34;weekly\u0026#34; if primary and primary.get(\u0026#34;name\u0026#34;) == \u0026#34;weekly\u0026#34; and secondary is None: return None, primary if secondary and secondary.get(\u0026#34;name\u0026#34;) == \u0026#34;five_hour\u0026#34; and primary is None: return secondary, None return primary, secondary def parse_rate_limits(data: JSONDict) -\u0026gt; tuple[JSONDict | None, JSONDict | None]: primary = None secondary = None for primary_key in (\u0026#34;five_hour\u0026#34;, \u0026#34;five_hour_limit\u0026#34;, \u0026#34;five_hour_rate_limit\u0026#34;, \u0026#34;primary\u0026#34;): if primary_key in data: primary = parse_limit_entry(\u0026#34;five_hour\u0026#34;, data.get(primary_key)) if primary: break for secondary_key in (\u0026#34;weekly\u0026#34;, \u0026#34;weekly_limit\u0026#34;, \u0026#34;weekly_rate_limit\u0026#34;, \u0026#34;secondary\u0026#34;): if secondary_key in data: secondary = parse_limit_entry(\u0026#34;weekly\u0026#34;, data.get(secondary_key)) if secondary: break if primary is None: primary = parse_limit_entry(\u0026#34;five_hour\u0026#34;, data.get(\u0026#34;primary_window\u0026#34;)) if secondary is None: secondary = parse_limit_entry(\u0026#34;weekly\u0026#34;, data.get(\u0026#34;secondary_window\u0026#34;)) return relabel_rate_limits(primary, secondary) def format_percent(value: Any) -\u0026gt; str: return f\u0026#34;{value:g}\u0026#34; if isinstance(value, (int, float)) else str(value if value is not None else \u0026#34;-\u0026#34;) def percent_sort_value(value: Any, descending: bool) -\u0026gt; tuple[int, float]: if isinstance(value, (int, float)): numeric_value = float(value) return (0, -numeric_value if descending else numeric_value) return (1, 0.0) def get_auth_paths(account_dir: str, account_name: str | None) -\u0026gt; list[Path]: base_dir = Path(account_dir) if account_name: return [base_dir / f\u0026#34;{account_name}.auth.json\u0026#34;] return sorted(base_dir.glob(\u0026#34;*.auth.json\u0026#34;)) def get_account_name_from_path(path: Path) -\u0026gt; str: suffix = \u0026#34;.auth.json\u0026#34; return path.name[: -len(suffix)] if path.name.endswith(suffix) else path.stem def build_summary_row(account_name: str, five_hour: JSONDict | None, weekly: JSONDict | None) -\u0026gt; JSONDict: return { \u0026#34;account\u0026#34;: account_name, \u0026#34;five_hour_percent\u0026#34;: five_hour[\u0026#34;percent_left\u0026#34;] if five_hour else None, \u0026#34;weekly_percent\u0026#34;: weekly[\u0026#34;percent_left\u0026#34;] if weekly else None, \u0026#34;weekly_reset_at\u0026#34;: weekly[\u0026#34;reset_at\u0026#34;] if weekly else None, } def print_summary_rows(rows: list[JSONDict]) -\u0026gt; None: if not rows: return sorted_rows = sorted( rows, key=lambda row: ( percent_sort_value(row.get(\u0026#34;five_hour_percent\u0026#34;), descending=True), percent_sort_value(row.get(\u0026#34;weekly_percent\u0026#34;), descending=True), format_cst(row.get(\u0026#34;weekly_reset_at\u0026#34;)), row[\u0026#34;account\u0026#34;], ), ) display_rows = [] for row in sorted_rows: display_rows.append( { \u0026#34;account\u0026#34;: str(row[\u0026#34;account\u0026#34;]), \u0026#34;five_hour\u0026#34;: format_percent(row.get(\u0026#34;five_hour_percent\u0026#34;)), \u0026#34;weekly\u0026#34;: format_percent(row.get(\u0026#34;weekly_percent\u0026#34;)), \u0026#34;weekly_reset\u0026#34;: format_cst(row.get(\u0026#34;weekly_reset_at\u0026#34;)), } ) headers = { \u0026#34;account\u0026#34;: \u0026#34;account\u0026#34;, \u0026#34;five_hour\u0026#34;: \u0026#34;five_hour%\u0026#34;, \u0026#34;weekly\u0026#34;: \u0026#34;weekly%\u0026#34;, \u0026#34;weekly_reset\u0026#34;: \u0026#34;weekly_reset\u0026#34;, } widths = { key: max(len(headers[key]), max(len(item[key]) for item in display_rows)) for key in headers } print( f\u0026#34;{headers[\u0026#39;account\u0026#39;]:\u0026lt;{widths[\u0026#39;account\u0026#39;]}} \u0026#34; f\u0026#34;{headers[\u0026#39;five_hour\u0026#39;]:\u0026gt;{widths[\u0026#39;five_hour\u0026#39;]}} \u0026#34; f\u0026#34;{headers[\u0026#39;weekly\u0026#39;]:\u0026gt;{widths[\u0026#39;weekly\u0026#39;]}} \u0026#34; f\u0026#34;{headers[\u0026#39;weekly_reset\u0026#39;]:\u0026lt;{widths[\u0026#39;weekly_reset\u0026#39;]}}\u0026#34; ) for item in display_rows: print( f\u0026#34;{item[\u0026#39;account\u0026#39;]:\u0026lt;{widths[\u0026#39;account\u0026#39;]}} \u0026#34; f\u0026#34;{item[\u0026#39;five_hour\u0026#39;]:\u0026gt;{widths[\u0026#39;five_hour\u0026#39;]}} \u0026#34; f\u0026#34;{item[\u0026#39;weekly\u0026#39;]:\u0026gt;{widths[\u0026#39;weekly\u0026#39;]}} \u0026#34; f\u0026#34;{item[\u0026#39;weekly_reset\u0026#39;]:\u0026lt;{widths[\u0026#39;weekly_reset\u0026#39;]}}\u0026#34; ) def validate_token_inputs( token: str, account_id: str, auth_token: str | None, auth_account_id: str | None, ) -\u0026gt; int | None: if token.startswith(\u0026#34;sess-\u0026#34;): print(\u0026#34;status: invalid_token_type\u0026#34;, file=sys.stderr) print( \u0026#34;message: --chatgpt-token looks like a session token (sess-...). Use the JWT access_token instead.\u0026#34;, file=sys.stderr, ) if auth_token: print( \u0026#34;hint: Found tokens.access_token in auth.json; omit --chatgpt-token or pass that value instead.\u0026#34;, file=sys.stderr, ) return 1 token_exp = decode_jwt_exp(token) if token_exp is not None and token_exp \u0026lt;= datetime.now(UTC): print(\u0026#34;status: expired\u0026#34;, file=sys.stderr) print(f\u0026#34;message: access_token expired at {format_dt(token_exp)}\u0026#34;, file=sys.stderr) if auth_token and auth_token != token: auth_token_exp = decode_jwt_exp(auth_token) hint = format_dt(auth_token_exp) if auth_token_exp else \u0026#34;unknown time\u0026#34; print(f\u0026#34;hint: auth.json contains a different access_token expiring at {hint}\u0026#34;, file=sys.stderr) return 1 if auth_account_id and account_id != auth_account_id: print(\u0026#34;warning: supplied --account-id does not match auth.json tokens.account_id\u0026#34;, file=sys.stderr) return None def handle_error_response(response: requests.Response, data: Any, raw_json: bool) -\u0026gt; int | None: if response.status_code == 401: print(\u0026#34;status: expired\u0026#34;, file=sys.stderr) print(\u0026#34;message: Token 已过期或无效\u0026#34;, file=sys.stderr) if raw_json: print_json(data) return 3 if response.status_code == 403: print(\u0026#34;status: forbidden\u0026#34;, file=sys.stderr) print(\u0026#34;message: 账号已被封禁或无权访问\u0026#34;, file=sys.stderr) if raw_json: print_json(data) return 3 if response.status_code \u0026gt;= 400: print(f\u0026#34;HTTP {response.status_code}\u0026#34;, file=sys.stderr) print_json(data) return 3 return None def fetch_chatgpt_usage(auth_path: Path, args: argparse.Namespace) -\u0026gt; tuple[int, JSONDict | None]: auth_data = load_auth_json(auth_path) account_name = get_account_name_from_path(auth_path) auth_token = get_nested_string(auth_data, \u0026#34;tokens\u0026#34;, \u0026#34;access_token\u0026#34;) auth_account_id = get_nested_string(auth_data, \u0026#34;tokens\u0026#34;, \u0026#34;account_id\u0026#34;) if not auth_data: print(f\u0026#34;{account_name}: auth file not found or invalid\u0026#34;, file=sys.stderr) return 1, None if not auth_token: print(f\u0026#34;{account_name}: missing access_token\u0026#34;, file=sys.stderr) return 1, None if not auth_account_id: print(f\u0026#34;{account_name}: missing account_id\u0026#34;, file=sys.stderr) return 1, None validation_error = validate_token_inputs( auth_token, auth_account_id, auth_token, auth_account_id, ) if validation_error is not None: return validation_error, None headers = { \u0026#34;Authorization\u0026#34;: f\u0026#34;Bearer {auth_token}\u0026#34;, \u0026#34;Accept\u0026#34;: \u0026#34;application/json\u0026#34;, \u0026#34;ChatGPT-Account-Id\u0026#34;: auth_account_id, \u0026#34;Origin\u0026#34;: \u0026#34;https://chatgpt.com\u0026#34;, \u0026#34;Referer\u0026#34;: \u0026#34;https://chatgpt.com/\u0026#34;, \u0026#34;User-Agent\u0026#34;: \u0026#34;Mozilla/5.0\u0026#34;, } try: response = requests.get(args.chatgpt_url, headers=headers, timeout=60) except requests.RequestException as exc: print(f\u0026#34;Request failed: {exc}\u0026#34;, file=sys.stderr) return 2, None if args.raw_headers: print(\u0026#34;=== Headers ===\u0026#34;) print_json(dict(response.headers)) print() try: data = response.json() except ValueError: print(f\u0026#34;HTTP {response.status_code}\u0026#34;, file=sys.stderr) print(response.text, file=sys.stderr) return 3, None error_response = handle_error_response(response, data, args.raw_json) if error_response is not None: return error_response, None if args.raw_json: print(\u0026#34;=== Raw JSON ===\u0026#34;) print_json(data) print() rate_limits = first_dict(data, \u0026#34;rate_limit\u0026#34;, \u0026#34;rate_limits\u0026#34;) if rate_limits is None: return 0, build_summary_row(account_name, None, None) five_hour, weekly = parse_rate_limits(rate_limits) return 0, build_summary_row(account_name, five_hour, weekly) def main() -\u0026gt; None: args = parse_args() auth_paths = get_auth_paths(args.account_dir, args.account_name) if not auth_paths: print(\u0026#34;No auth files found.\u0026#34;, file=sys.stderr) sys.exit(1) exit_code = 0 summary_rows: list[JSONDict] = [] for auth_path in auth_paths: current_exit_code, summary_row = fetch_chatgpt_usage(auth_path, args) exit_code = max(exit_code, current_exit_code) if summary_row is not None and not args.raw_json: summary_rows.append(summary_row) if summary_rows: print_summary_rows(summary_rows) sys.exit(exit_code) if __name__ == \u0026#34;__main__\u0026#34;: main() ","date":"2026-04-12T00:01:33+08:00","permalink":"https://www.knightli.com/ja/2026/04/12/codex-usage-quota-check/","title":"Codex クォータ使用統計"},{"content":"gemma-4-31B-it という名前の it は、「命令微調整」バージョンである Instruction Tuned の略称です。\nほとんどの人にとって、これは次のように理解できます。このモデルは、チャット、Q\u0026amp;A、コードの作成、および明示的なタスクの実行により適しています。\nitとは\rモデルには通常、次の 2 つの一般的なバージョンがあります。\n基本/事前トレーニング済み: 元のテキスト予測子に近い基本モデル。 it: コマンドを微調整した後、「何をしてもらえますか?」などの入力をよりよく理解できるようになりました。 「これを翻訳してください」または「この Python コードを書いてください」と入力した場合、通常、it バージョンの方が安定しており、より会話的です。\n31Bとは\r31B は、このモデルに約 310 億のパラメーターがあることを意味します。\n一般的に言えば:\nパラメーターの数が増えるほど、モデルの機能と知識の範囲が強化される傾向があります。 同時に、ビデオ メモリやメモリの要件も高くなります。 そのため、31B は比較的大規模なモデルとなり、動作閾値が高くなります。\nGemma-4 とはどういう意味ですか?\rGemma-4 はモデル シリーズと世代を表します。\nGemma: Google のオープンソース モデル シリーズ 4: シリーズの第 4 世代バージョン 選び方\rチャット、Q\u0026amp;A、翻訳、またはコードの作成が目的の場合は、通常、-it を備えたバージョンが推奨されます。\n下位レベルの調査、微調整、またはカスタム トレーニング タスクを実行している場合は、基本バージョンをチェックアウトする可能性が高くなります。\n一文の要約\rgemma-4-31B-it は、Gemma 4 シリーズ、310 億のパラメーター、ダイアログおよびコマンド タスクに適したバージョンとして直接理解できます。\n","date":"2026-04-11T20:45:34+08:00","permalink":"https://www.knightli.com/ja/2026/04/11/gemma-4-31b-it-meaning/","title":"Gemma-4-31B ではどういう意味ですか?"},{"content":"Hugging Face で Llama の GGUF モデルを選択する場合、まず量子化レベルを「解像度」として理解できます。解像度が低いほど使用する VRAM/RAM は少なくなりますが、品質は徐々に低下します。\nまずは32、16、Qシリーズについて理解しましょう\r32: 最高品質のオリジナルの非圧縮バージョンとして理解できますが、ハードウェア要件は非常に高くなります。 16: 元の品質に近く、サイズは 32 の約半分で、より実用的です。 Q8: ここから量子化バージョンが来ます。通常は Q8_0 または Q8 と書かれます。 Q6、Q5、Q4、Q3、Q2: 数値が小さいほど、リソースの使用量が低くなり、目に見える品質の低下が発生しやすくなります。 K_M / K_Sとは\rK_M および K_S は、ハイブリッド量子化戦略を表します。\nほとんどの重みは現在の量子化レベルを使用します 一部の主要部品はより高い精度を維持 したがって、同じレベルでは、Qx_K_M または Qx_K_S は、通常、純粋な Qx よりもわずかに優れています。\n実用的な選択の提案\r十分なハードウェア: 優先順位 Q8。 ビデオ メモリまたはメモリが不足しています: Q6 / Q5 / Q4 まで段階的にダウンします。 下限の提案: Q4 を下回らないようにし、Q4_K_M を優先します。 Q3 以下: 品質の低下がますます顕著になります。 品質の勾配 (高から低)\r32 16 \u0026ndash; この点を超えると、品質は同じですが、ハードウェア要件が非常に高くなります \u0026ndash;\nQ8 Q6_K_M Q6_K_S Q6 Q5_K_M Q5_K_S Q5 \u0026ndash; これが古典的なスイートスポットです \u0026ndash;\nQ4_K_M Q4_K_S Q4 \u0026ndash; この点を下回ると、品質の低下が顕著になります \u0026ndash;\nQ3_K_M Q3_K_S Q3 Q2_K_M Q2_K_S Q2 単純な結論が必要な場合: ほとんどのシナリオでは、Q8 または Q6_K_M から開始するだけでは十分ではなく、通常は Q5 または Q4_K_M にダウングレードする方が安全です。\n","date":"2026-04-11T20:07:29+08:00","permalink":"https://www.knightli.com/ja/2026/04/11/llama-gguf-quantization-selection/","title":"Llama の GGUF モデルを選択するときの量子化の選択方法: Q8 から Q2 までの実践的な提案"},{"content":"LAN 内の他のデバイスがローカル Ollama API にアクセスできるようにする場合は、次のように設定できます。\nリスニングポートを設定する\rまず、Ollama リスニング アドレスをすべてのネットワーク カードに変更します。\nOLLAMA_HOST=0.0.0.0:11434\nファイアウォールを開く\r詳細なファイアウォール設定を開いた後、新しい受信ルールを作成し、ターゲット ポート (8080 など) を許可します。\nWin + S を押して、「Windows Defender ファイアウォール」を検索して開きます。 「詳細設定」をクリックします。 「受信ルール」→「新しいルール\u0026hellip;」を選択します。 ルールの種類として「ポート」を選択し、「次へ」をクリックします。 プロトコル（通常はTCP）を選択し、「特定のローカルポート」に開放するポート番号（例：8080）を入力し、「次へ」をクリックします。 「接続を許可する」を選択し、「次へ」をクリックします。 「プロファイル」の「ドメイン」「プライベート」「パブリック」にチェックを入れて「次へ」をクリックします。 ルールに名前を付けて (OpenPort8080 など)、「完了」をクリックします。 ラン・オラマ\rオラマランモデル\nAPI経由でモデルにアクセス\r1 2 3 4 curl http://192.168.x.xxx:11434/api/generate -d \u0026#39;{ \u0026#34;model\u0026#34;: \u0026#34;gemma4\u0026#34;, \u0026#34;prompt\u0026#34;: \u0026#34;这个是什么模型?\u0026#34; }\u0026#39; ","date":"2026-04-11T16:43:52+08:00","permalink":"https://www.knightli.com/ja/2026/04/11/ollama-api-lan-access-windows/","title":"Windows LAN Access Ollama API セットアップ ガイド"},{"content":"USB PD 電源ソリューションを作成する場合、一般的なデコイ チップは、電圧機能、プロトコルの互換性、コストに基づいて大まかに選択できます。\nチップ比較\r芯片 主要特点 适用场景 CH224K（沁恒） 热门、性价比高，可外接电阻配置，最高 20V 输出 大功率取电、通用 PD 方案 HUSB238（慧能泰） 体积小、集成度高，符合 USB PD3.0，支持 PPS 与 PD3.1 28V 小体积且需要更高电压输出的设备 HUSB237（慧能泰） 极简 PD Sink，支持 PD3.1（5V/9V/12V/15V/20V）、最高 20V/5A（100W），支持 SOP\u0026rsquo;（eMarker 模拟）、BC1.2 与 QC2.0 追求极简外围和高性价比的取电方案，尤其是 100W 线缆应用 IP2721（英集芯） 支持插拔自动检测，兼容 PD2.0/3.0，稳定性好 需要自动识别与协议处理的产品 XSP 系列（如 XSP01/XSP05） 性价比高，支持 PD + QC + FCP + SCP + AFC 多协议快充设备，如手机适配器、无线充电模组 選択の提案\r成熟性と低コストを追求：CH224KまたはXSPシリーズを優先。 高集積化、高電圧化を追求：HUSB238を優先。 ミニマルな周辺機器を追求し、100W (20V/5A) の機能をカバーする場合は、HUSB237 を優先できます。 強力なプロトコル処理と自動検出が必要です。まず IP2721 を確認してください。 ","date":"2026-04-11T13:10:58+08:00","permalink":"https://www.knightli.com/ja/2026/04/11/usb-pd-decoy-chip-comparison/","title":"一般的な USB PD デセプション チップの比較: CH224K、HUSB238、HUSB237、IP2721、XSP"},{"content":"Feiniu NAS (fnOS) の AI フォト アルバムは、一連のアルゴリズムを一から開発するのではなく、主流のオープンソース モデルに基づいてエンジニアリングを統合し、顔認識、シーン認識、自然言語画像検索を完成させます。\n1) 顔認識: InsightFace\r顔の機能に関しては、通常、コアは InsightFace です。\n一般的な特徴抽出方法: ArcFace 主な機能: 顔の検出、特徴ベクトルの抽出、顔クラスタリング、文字認識の実行 2) ターゲット検出とシーン認識：YOLOシリーズ\rオブジェクト認識 (猫、犬、車、コンピューターなど) と写真内の部分的なシーンの理解は通常、YOLO シリーズ (通常は YOLOv8 または軽量バージョン) によって行われます。\n利点: 精度と速度のバランスが良い 適応シナリオ: NAS などのエッジデバイスの限られたコンピューティング能力環境 3) 意味検索: CLIP / Chinese-CLIP\rFeiniu Photo Album は、「草の上の子犬」や「サングラスをかけた男性」など、自然言語を使用した写真の検索をサポートしています。\n一般的な実装は CLIP です。\n画像とテキストは同じベクトル空間にマッピングされます 中国語のシナリオでは、通常、 Chinese-CLIP または同様の中国語の拡張ソリューションと組み合わせられます。 要約する\rFeiniu AI フォト アルバムは、次の 3 層の組み合わせとして理解できます。\nInsightFace は人間の顔を担当します YOLO はオブジェクトとシーンを担当します CLIP は人間の言語を画像のセマンティクスに合わせる役割を果たします。 中核となる競争力は、基盤となるモデルをゼロからトレーニングするのではなく、主にエンジニアリングの統合、ローカリゼーション機能、ハードウェア アクセラレーションの最適化にあります。\n","date":"2026-04-11T08:27:57+08:00","permalink":"https://www.knightli.com/ja/2026/04/11/fnos-ai-photo-model-stack/","title":"Feiniu NAS AI フォト アルバムで使用されているモデル: 顔、オブジェクトの分解、セマンティック検索"},{"content":"この記事では、go2rtc を使用して Xiaomi カメラ ストリームを直接取得し、それを NVR、HomeKit、および Frigate に均一に分散する方法を記録します。\nDocker のデプロイメント例\r1 2 3 4 5 6 7 8 9 10 11 services: go2rtc: container_name: go2rtc image: alexxit/go2rtc:master-hardware restart: always network_mode: host privileged: true environment: - TZ=Asia/Shanghai volumes: - /vol1/1000/docker/go2rtc:/config go2rtc バックエンド アドレス:\n1 http://192.168.3.217:1984/ ストリーム構成例\r1 2 3 4 5 6 7 8 9 10 streams: micam1: - xiaomi://xxx #H265转H264,Homekit预览会用到 #micam1_h264: #- ffmpeg:micam1#video=h264#width=1280#height=720#hardware#raw=-r 15 micam2: - xiaomi://xxx micam3: - xiaomi://xxx RTSP ストリーム アドレスの形式:\n1 rtsp://192.168.3.217:8554/micam1 画質とパラメータ\r画質は 0 ～ 5 で指定します。\n0 は通常、自動を意味します 1 は sd を意味します 2 は hd を意味します (go2rtc のデフォルト) 一部の新しいカメラは、3 で HD を備えている場合があります。古いモデルでは、3 のコーデック構成が壊れている可能性があるため、フリーサイズは推奨されません。\nsubtype=hd/sd/auto/0-5 を介して画質を指定できます。\n1 2 streams: xiaomi1: xiaomi://***\u0026amp;subtype=sd 2 番目のチャンネル パラメーター channel=2 は、デュアルカメラ シーンで使用できます。\n1 2 streams: xiaomi1: xiaomi://***\u0026amp;channel=2 まとめ\rgo2rtc による統合ストリーミング後は、RTSP を NVR 録画、Frigate 分析、HomeKit プレビューに同時に使用できるようになり、メンテナンス コストが大幅に削減されます。\n参考リンク\rカメラサポートリスト: https://github.com/AlexxIT/go2rtc/issues/1982 公式説明ソース: https://github.com/AlexxIT/go2rtc/blob/master/internal/xiaomi/README.md Docker イメージ: https://hub.docker.com/r/alexxit/go2rtc ","date":"2026-04-11T08:14:47+08:00","permalink":"https://www.knightli.com/ja/2026/04/11/go2rtc-xiaomi-rtsp-nvr-homekit-frigate/","title":"go2rtc は Xiaomi カメラ RTSP に直接接続します。NVR、HomeKit、Frigate に接続します。"},{"content":"Gemma 4 (2026 年に Google がリリースした新世代のオープンソース モデル) をローカルで呼び出したい場合は、ニーズに応じてこれら 4 種類のソリューションから選択できます。\n1) 最も早く始める: Ollama (推奨)\rこれは最も障壁の低いアプローチであり、簡単なテスト、日常会話、ローカル API 呼び出しに適しています。\n1 ollama run gemma4 特徴：\nWin/Mac/Linux で利用可能 ハードウェアアクセラレーションを自動的に処理します OpenAIスタイルに対応したネイティブAPIを提供 2) グラフィカルインターフェイス: LM Studio / Unsloth Studio\rデスクトップ GUI (ChatGPT に似たもの) に慣れている場合は、これら 2 種類のツールの方が便利です。\nLM Studio:Hugging Face で Gemma 4 量子化モデル (4 ビット、8 ビットなど) を直接検索してダウンロードし、リソースの使用状況を表示できます。 Unsloth Studio: 推論に加えて、低メモリ微調整もサポートしています。 6GB～8GBのビデオメモリを搭載したマシンにさらに優しい。 3) 低構成と究極の制御: llama.cpp\r古いマシン、純粋な CPU シナリオ、または推論パラメーターを詳細に制御したいユーザーに適しています。\n量子化バージョンで .gguf モデル ファイルを使用すると、より低いハードウェアしきい値で Gemma 4 を実行できます。\n4) 開発統合: Transformers/vLLM\rGemma 4 を独自のアプリケーションに統合したい場合:\nTransformers: Python プロジェクトにモデルを直接ロードするのに適しています vLLM: 高性能 GPU シナリオおよび高スループット推論サービスに適しています クイック選択\r需求 推荐工具 硬件门槛 我只想马上跑起来 Ollama 低（自动适配） 我更喜欢图形界面 LM Studio 中 显存很紧张（6GB-8GB） Unsloth / llama.cpp 低 我要做本地 AI 应用开发 Ollama / Transformers / vLLM 中到高 我要做微调训练 Unsloth Studio 中到高 モデルの推奨サイズ\rGemma 4 はさまざまなサイズで利用できます (E2B、E4B、31B など)。\n通常のオフィスのラップトップの場合は、定量化された E2B/E4B が推奨されます。 ビデオ メモリに余裕がある場合は、より大きなバージョンを試してください。 ","date":"2026-04-10T22:54:17+08:00","permalink":"https://www.knightli.com/ja/2026/04/10/gemma4-local-runtime-options/","title":"Gemma 4 ローカル通話ガイド: ワンクリック実行から開発統合まで"},{"content":"過去 1 年間、エージェント ツールチェーンに関する議論は、次の 1 つの問題にますます集中してきました。\nMCP (モデル コンテキスト プロトコル) はツールの呼び出しを簡単にしますか? それとも、もともと単純だったものを複雑にしますか?\nCLI は、ほとんどの日常的な開発タスクにとって、より実用的なデフォルトになりつつあります。\nコストの違いは「経験の問題」ではなく、桁違いの問題です\rMCP に対する実際の最大のプレッシャーはトークンのオーバーヘッドです。\n一般的なシナリオでは、MCP は実際にタスクを実行する前に、多数のツール スキーマをロードする必要があります。 GitHub MCP サーバーを例に挙げると、初期化で数万のトークンが消費される可能性があります。長いタスクの場合、これはコンテキスト バジェットを直接圧迫します。\nコミュニティのベンチマークは、同じ結論を繰り返し示しています。\n1 回の MCP 呼び出しのコストは、通常、CLI の数倍から数十倍になります。 失敗した再試行のコストも高くなります (接続の再構築とコンテキストの再ロード)。 これは「遅い」というギャップではなく、むしろ API 料金、レイテンシー、安定性の問題にまで拡大します。\nモデルが自然に「CLI に精通している」理由\r見落とされがちな事実は、トレーニングの分布です。\nLLM は、トレーニング中にコマンド、出力、エラー レポート、スクリプト、マニュアル ページなどの大量の端末テキストを確認しました。言い換えれば、CLI 対話モードは本質的にモデルの「母国語入力」に近いものになります。\nそれどころか、MCP の JSON-RPC とツール スキーマは、ここ 2 年間で大規模に登場したばかりの新しいパラダイムです。モデルは確かに学習できますが、親しみやすさと圧縮効率は通常、CLI などの歴史的コーパスほど良くありません。\nこれは、その理由を何度も説明するものでもあります。\n目標は同じですが、CLI 命令は短くなります 出力は推論を直接続行するのにより適しています。 エラー回復パスの安定性が向上 安全と隔離：MCPにはまだ補講の余地があります\rMCP がセキュリティを実現できないわけではありませんが、エコシステムはまだ初期段階にあります。\n現在の一般的な懸念事項は次のとおりです。\nツール中毒 サービス動作のドリフト (ラグプル) 同名のツール「シャドウイング」 もちろん、CLI にもセキュリティの問題 (インジェクション、不正アクセス、パスのリスク) がありますが、そのプロセス モデル、権限の境界、監査リンクは数十年にわたるエンジニアリングの実践によって検証されています。本番環境では、この「予測可能性」が重要です。\nこれはMCPが無価値であるという意味ではありません\r私はMCPを放棄すべきではないと思います。\nより合理的な位置付けは次のとおりです。\nCLI は実行層 (ローカル、低遅延、高頻度の呼び出し) を担当します。 MCP は接続層 (リモート サービス ディスカバリ、統合認証、監査、マルチテナント) を担当します。 一般に、ハイブリッド アーキテクチャ: CLI + MCP Gateway とも呼ばれます。\n多数のリモート システムに接続し、統合された権限管理とコンプライアンス監査を実行する必要がある場合、MCP には依然として明白な価値があります。しかし、「エージェントが開発タスクを迅速に完了できるようにする」という点では、多くの場合、CLI ファーストの方が現在のモデルの機能の境界に沿っています。\n今日のエンジニアリングの現実では、CLI はエージェントの母国語に似ています。 MCP は、唯一の実行プロトコルではなく、接続プロトコルとして適しています。\n","date":"2026-04-10T21:55:12+08:00","permalink":"https://www.knightli.com/ja/2026/04/10/mcp-vs-cli-for-agents/","title":"MCPを捨てますか？ CLI がエージェントのデフォルトのツール層になりつつある理由"},{"content":"PersonaPlex は、リアルタイムの全二重音声対音声会話モデルです。次の 2 種類の制御可能な機能をサポートします。\nテキストの役割プロンプトを通じて「性格と話し方」を制御する オーディオ条件で「音色とサウンドスタイル」をコントロールする これは Moshi アーキテクチャと重みに基づいており、その目標は、より自然でペルソナに一貫した音声インタラクションを低遅延で出力することです。\nそれを使って何ができるか\rPersonaPlex は次のシナリオに適しています。\nリアルタイム音声アシスタント 顧客サービスの役割に関する対話 低遅延の音声プレゼンテーションおよび対話システム 声の特徴付け実験（キャラクターデザイン＋音色） 導入前の準備\rまず、Opus 開発ライブラリをインストールします。\n1 2 3 4 5 # Ubuntu/Debian sudo apt install libopus-dev # Fedora/RHEL sudo dnf install opus-devel インストールと環境構成\rリポジトリをインストールします。\n1 pip install moshi/. Blackwell GPU はさらに次のことを実行できます。\n1 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130 Hugging Face にログインし、PersonaPlex モデル ライセンスに同意した後、トークンを構成します。\n1 export HF_TOKEN=\u0026lt;YOUR_HUGGINGFACE_TOKEN\u0026gt; リアルタイムサービスを開始する\r標準起動 (一時 SSL を使用):\n1 SSL_DIR=$(mktemp -d); python -m moshi.server --ssl \u0026#34;$SSL_DIR\u0026#34; ビデオ メモリが不足している場合、CPU オフロードを有効にできます (accelerate が必要)。\n1 2 pip install accelerate SSL_DIR=$(mktemp -d); python -m moshi.server --ssl \u0026#34;$SSL_DIR\u0026#34; --cpu-offload ローカル アクセスは通常、localhost:8998 です。リモートにデプロイされている場合は、スクリプトによって出力されたアクセス リンクを使用します。\nオフライン評価\rオフライン スクリプトは、wav を入力し、同じ長さの wav 結果を出力できます。\n1 2 3 4 5 6 7 HF_TOKEN=\u0026lt;TOKEN\u0026gt; \\ python -m moshi.offline \\ --voice-prompt \u0026#34;NATF2.pt\u0026#34; \\ --input-wav \u0026#34;assets/test/input_assistant.wav\u0026#34; \\ --seed 42424242 \\ --output-wav \u0026#34;output.wav\u0026#34; \\ --output-text \u0026#34;output.json\u0026#34; 1 2 3 4 5 6 7 8 HF_TOKEN=\u0026lt;TOKEN\u0026gt; \\ python -m moshi.offline \\ --voice-prompt \u0026#34;NATM1.pt\u0026#34; \\ --text-prompt \u0026#34;$(cat assets/test/prompt_service.txt)\u0026#34; \\ --input-wav \u0026#34;assets/test/input_service.wav\u0026#34; \\ --seed 42424242 \\ --output-wav \u0026#34;output.wav\u0026#34; \\ --output-text \u0026#34;output.json\u0026#34; プリセットサウンド\r固定トーンラベルは次のとおりです。\nNatural(female): NATF0, NATF1, NATF2, NATF3 Natural(male): NATM0, NATM1, NATM2, NATM3 Variety(female): VARF0, VARF1, VARF2, VARF3, VARF4 Variety(male): VARM0, VARM1, VARM2, VARM3, VARM4 プロンプトワードの使用に関する提案\r公式トレーニングでは、次の 3 つの主要なタイプのシナリオがカバーされます。\nアシスタントの役割 (Q\u0026amp;A アシスタント) カスタマーサービスの役割 カジュアルな会話（日常のオープンな会話） 実践的な提案:\nまずロール情報を修正してから、ビジネス コンテキストを追加します 文字のずれを避けるためにプロンプ​​トワードの長さを制御する 同じ音声プロンプトを使用して反復可能な比較テストを実行する 要約する\rPersonaPlex の利点は、「一度でよりインテリジェントな回答ができること」ではなく、「リアルタイムの音声対話において、キャラクターと音声の一貫性がより安定して維持されること」です。\n全二重音声エージェントを構築している場合、このソリューションはできるだけ早く実際にテストして比較する価値があります。\n","date":"2026-04-10T11:34:38+08:00","permalink":"https://www.knightli.com/ja/2026/04/10/personaplex-full-duplex-speech-model-guide/","title":"PersonaPlex 入門ガイド: 音色とキャラクターを制御できる全二重音声対話モデル"},{"content":"Anthropic は最近、Harness のエンジニアリング実践に関する記事を公開しました。表面的には製品の実装について話しているように見えますが、本質的には長期的な質問に答えています。\n**モデルの機能が変化し続ける場合、エージェント システムのどのレイヤーが安定している必要があり、どのレイヤーが迅速な置き換えを可能にする必要がありますか? **\n核心判断\rこの記事に関する私の基本的な理解は、エージェント インフラストラクチャがますます軽量の エージェント OS に近づいていくだろうということです。\n焦点は「今日の最良のプロセスをハードコーディングする」ことではなく、「長期的に安定したシステム抽象化を定義する」ことにあります。\nこれがなぜ重要なのでしょうか?\r多くのエージェント フレームワークに共通する問題は次のとおりです。\nモデルの一時的な欠点を永続的な構造に統合します。 プロンプトプロジェクトをシステム境界と間違えた 長期的な依存関係として一度有効なパッチを作成する モデルはより強力になり、今日合理的なパッチが明日には技術的負債になる可能性があります。\n人間的ソリューション: コンクリートハーネスからメタハーネスへ\rこのアイデアは、固定された配置方法を約束するものではありませんが、安定したインターフェイスの 3 つの層を抽象化します。\nsession: 回復可能なイベントとステータスの履歴 harness: 推論とスケジューリングのループ (脳) sandbox: 実行環境とツールの機能 (ハンド) 分離すると、システムの交換、復旧、拡張が容易になります。\n1) セッションはコンテキスト ウィンドウではありません\r重要な点は次のとおりです。 **セッションはモデル コンテキストと等しくありません。 **\nセッションは、モデルに直接接続された履歴のスプライシングではなく、クエリ可能、再生可能、および回復可能なイベント ログである必要があります。\nこれを行うことの価値:\nトリミングは歴史の消滅を意味するものではありません 圧縮は事実の損失と同等ではない クラッシュリカバリは、サマリーメモリに依存するのではなく、イベントレイヤーに戻ることができます 2) ハーネスは交換可能なオーケストレーション レイヤーです\rハーネスは、ビジネス ステータスを保持することよりも、スケジュールを管理することに重点を置く必要があります。\n理想的なインターフェイスは次のようなものです。\nexecute(name, input) -\u0026gt; string\nこれは、モデルが「どの機能を呼び出すことができるか」のみを考慮しており、特定のデバイス、コンテナー、オペレーティング システムに強く束縛されていないことを意味します。\n3) サンドボックスは「頭脳」ではなく「手」です。\r脳と手が切り離されると:\nツール環境は独立して進化できる 異なるインフラストラクチャに並行してアクセス可能 セッションごとに実行環境全体をウォームアップする必要はありません これは、起動および拡張のパフォーマンスの向上に直接つながります。\nパフォーマンスとセキュリティのインスピレーション\r多くの場合、この分割によりパフォーマンスとセキュリティの両方が向上します。\nパフォーマンス：\n最初に脳を起動し、必要に応じて手を引き上げることができます 最初のトークンの遅延を減らす (TTFT) 安全性：\n機密性の高い認証情報をモデルに直接公開しないでください 間接的な資格情報アクセスには制御されたプロキシ/ボールトを使用する 安全境界はシステムの制約に基づいており、「モデルが実行できないこと」ではありません。 関連リンク\rUsage patterns and customer examples The design of Claude Managed Agents Onboarding, quickstart, overview of the CLI and SKDs ","date":"2026-04-10T09:22:56+08:00","permalink":"https://www.knightli.com/ja/2026/04/10/anthropic-harness-agent-os/","title":"Anthropic の Harness アイデア: エージェント インフラストラクチャはエージェント OS に移行しています"},{"content":"初めて OpenClaw に触れた人の多くは、「チャットボットというよりも、何かができる同僚に近い」と感じるでしょう。\nこの感覚には何も不思議なことはありません。重要な点は、OpenClaw は単一モデルの機能を飛躍的に向上させたものではなく、完全な エージェント ハーネス であるということです。\n結論を先に言ってください\rOpenClaw の本質は次のように要約できます。\nモデルは理解と意思決定を担当します ハーネスはメモリ、ツール、トリガー、実行、出力を担当します。 両者はサイクルを通じて協力し、「継続的なアクション」の体験を形成します。 したがって、それが「AGI に似ている」主な理由は、モデルが突然全能になることではなく、システム エンジニアリングによってモデルの実行可能性が増幅されることです。\nハーネスとは\rハーネスは「モデルが着用する外骨格」と理解できます。\nスタンドアロン LLM は通常、単一のリクエストでのみ回答を提供でき、Harness はこれらの機能を完了します。\nセッションと状態の管理: 複数のラウンドのタスクをつなぎ合わせる メモリメカニズム: オンデマンドでコンテキストを保存および呼び出し ツール システム: ブラウザ、端末、ファイル、外部 API の呼び出し トリガーメカニズム: タイマーまたはイベントによって起動し、毎回誰かが質問するのを待つ必要はありません。 出力チャネル: 単なるテキストではなく、結果をシステムに書き戻します。 これらの機能が同じループに接続されると、モデルは「レスポンダー」から「エグゼキューター」に変わります。\nOpenClaw の外観が異なる理由\r従来のチャットボットは「1 回質問し、1 回回答」です。\nOpenClaw は、「観察 -\u0026gt; ツールの調整 -\u0026gt; 結果の確認 -\u0026gt; 意思決定」という閉ループに似ています。クローズドループが確立されると、タスクを継続的に進める能力を発揮します。\nこれは、OpenClaw について学ぶべき最も価値のあることでもあります。\nエージェントのエクスペリエンスは主にアーキテクチャ設計から得られることが証明されています 「自律性」をエンジニアリングモジュールに分割します 価値観と境界線\rOpenClaw の利点は多用途性と柔軟性があることですが、価格も明らかです。\nコンテキストとツールの定義が増えるほど、コストが高くなります システムが一般的であればあるほど、デバッグと管理はより複雑になります 本番環境のシナリオでは、多くのチームが「万能エージェント」ではなく、より小規模で専門性の高いエージェントを選択します。\n","date":"2026-04-10T09:16:17+08:00","permalink":"https://www.knightli.com/ja/2026/04/10/openclaw-agent-architecture-enterprise-ai/","title":"OpenClaw と Agent Harness: なぜ AGI のように見えるのか"},{"content":"product-cutout-normalize は、商品画像に使用されるエージェント スキルです。\n元画像を統一仕様の下透明正方形画像に加工します。デフォルトのルールは次のとおりです。\n1024x1024 キャンバス 透明な背景 件名は可能な限り完全なものにしてください 縦長の被写体を横長に自動変換 センターボディ メインの表示幅は820pxに統一 電子商取引資料、製品ライブラリ、詳細ページの画像の前処理に適しています。\nこのスキルはどのような問題を解決しますか?\r多くの製品画像には、基本的な切り抜き後も次の問題が発生します。\n白い枠または薄い灰色の背景が残る 被写体の水平方向と垂直方向が一致しない キャンバスのサイズが不安定です 被写体のサイズは大きいものから小さいものまでさまざまです 透明部分に小さなノイズがある このスキルは一定のプロセスに従って処理されます。\nジェミニのカットアウト 明るい背景のエッジをクリーンアップ ノイズの小さな断片を除去する 縦長画像を横長画像に変換 ターゲットの幅に合わせて拡大縮小する 均一なサイズの透明なキャンバスの中央に配置します。 この方法でエクスポートされた画像はよりきれいになり、バッチ使用に適しています。\n該当するシナリオ\r以下のニーズに適しています。\n商品写真をバッチ処理する 下透過PNGの統合出力 メインビジュアルのサイズを統一する 安定した反復可能な処理手順が必要 少数の画像のみを扱う場合、または各画像のレイアウトを個別に調整する必要がある場合には、これは適さない可能性があります。\nクイックスタート\r最も直接的な実行方法:\n1 \u0026amp; \u0026#34;.\\.venv\\Scripts\\python.exe\u0026#34; \u0026#34;.codex\\skills\\product-cutout-normalize\\scripts\\run_pipeline.py\u0026#34; \u0026#34;input_dir\u0026#34; \u0026#34;output_dir\u0026#34; --overwrite 実行前に必須:\nGEMINI_API_KEY google-genai Pillow 依存関係をインストールします。\n1 .\\.venv\\Scripts\\python.exe -m pip install google-genai pillow 環境変数を設定します。\n1 $env:GEMINI_API_KEY=\u0026#34;your_api_key\u0026#34; 出力ルール\rデフォルトの出力:\n透明な背景 PNG 1024x1024 キャンバス 身幅820px センターボディ 小さなノイズもクリーンアップされます つまり、これは単なるスクリプトの暗記ではなく、製品イメージを整理するスクリプトのようなものです。\n主なパラメータの説明\r一般的に使用されるパラメータ:\n--model デフォルト gemini-2.5-flash-image --canvas-size 出力正方形キャンバス サイズ、デフォルト 1024 --target-width 本体の表示幅、デフォルトは 820 --min-component-pixels このピクセル数より小さい透明なフラグメントは削除されます (デフォルトは 500) --overwrite 出力ファイルがすでに存在する場合は、出力ファイルを直接上書きします 例えば：\n1 \u0026amp; \u0026#34;.\\.venv\\Scripts\\python.exe\u0026#34; \u0026#34;.codex\\skills\\product-cutout-normalize\\scripts\\run_pipeline.py\u0026#34; \u0026#34;.\\input\u0026#34; \u0026#34;.\\output\u0026#34; --canvas-size 1280 --target-width 960 --overwrite 処理の流れ\r処理フローは簡単です。\nジェミニのカットアウト 明るい背景のエッジをクリーンアップ ノイズの小さな断片を除去する 縦長画像を横長画像に変換 ターゲットの幅に合わせて拡大縮小する 均一なサイズの透明なキャンバスの中央に配置します。 通常の切り抜きスクリプトとの違い\r通常の暗記スクリプトと比較して、次の問題もさらに処理します。\n主な方向性は統一されています 均一なボディサイズ 均一なキャンバスサイズ 小さな破片やノイズ​​のクリーンアップ 結果はマテリアル ライブラリに直接入れるのに適しています。 SKILL.md ソースコード\rSKILL.md の完全なソース コードは以下に保持されており、内容は変更されていません。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 --- name: product-cutout-normalize description: Run a reusable Gemini product-image pipeline that removes backgrounds, preserves the full subject, rotates tall products to a horizontal orientation, centers them on a 1024x1024 transparent canvas, and normalizes the visible subject width to 820px. Use when the user wants a repeatable cutout-and-normalize workflow for product photos or asks to batch-process product images into standardized square PNG assets. --- # Product Cutout Normalize Use this skill when product photos need the same deterministic finishing pipeline: - Gemini cutout from the original photo - border cleanup to transparent - preserve the full subject - rotate to horizontal when the subject is taller than it is wide - center on a `1024x1024` transparent canvas - normalize the visible subject width to `820px` ## Quick Start Run the bundled script: ```powershell \u0026amp; \u0026#34;.\\.venv\\Scripts\\python.exe\u0026#34; \u0026#34;.codex\\skills\\product-cutout-normalize\\scripts\\run_pipeline.py\u0026#34; \u0026#34;input_dir\u0026#34; \u0026#34;output_dir\u0026#34; --overwrite ``` Required environment: - `GEMINI_API_KEY` - `google-genai` - `Pillow` ## Workflow 1. Confirm the request matches this standard pipeline. If the user asks for a different canvas size, subject width, or layout rule, pass explicit flags instead of changing the script. 2. Run the bundled script on the input directory. 3. If a result looks misaligned, inspect the alpha bounding box and small detached artifacts first; this pipeline already removes tiny alpha components by default. 4. Report the exact input and output directories used, plus any non-default flags. ## Script Primary entry point: - `scripts/run_pipeline.py` Key flags: - `--model`: Gemini image model, default `gemini-2.5-flash-image` - `--canvas-size`: output square size, default `1024` - `--target-width`: visible subject width after normalization, default `820` - `--min-component-pixels`: remove detached alpha specks smaller than this, default `500` - `--overwrite`: replace existing outputs in the destination directory ## Repo Integration If the current project already has [`scripts/nano_banana_cutout.py`](/c:/Work/my_shop/scripts/nano_banana_cutout.py), prefer that repo script when the user wants the same pipeline inside this repository. Use the bundled skill script when the task is cross-project reuse or when you want the workflow to stay self-contained inside the skill. スクリプト/run_pipeline.py ソース コード\rscripts/run_pipeline.py の完全なソース コードは以下に保持されており、内容は変更されていません。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 from __future__ import annotations import argparse import os from collections import deque from pathlib import Path from PIL import Image try: from google import genai except ImportError as exc: # pragma: no cover raise SystemExit( \u0026#34;Missing dependency: google-genai. Install it with \u0026#34; r\u0026#34;\u0026#39;.\\.venv\\Scripts\\python.exe -m pip install google-genai\u0026#39;.\u0026#34; ) from exc PROMPT = ( \u0026#34;Remove the entire background from this product photo and return only the product \u0026#34; \u0026#34;on a fully transparent background as a PNG. Keep the full product intact, preserve \u0026#34; \u0026#34;thin cable details, clean the inner loops and holes, and do not add any new objects \u0026#34; \u0026#34;or shadows.\u0026#34; ) DEFAULT_CANVAS_SIZE = 1024 DEFAULT_TARGET_WIDTH = 820 DEFAULT_MIN_COMPONENT_PIXELS = 500 SUPPORTED_EXTENSIONS = {\u0026#34;.jpg\u0026#34;, \u0026#34;.jpeg\u0026#34;, \u0026#34;.png\u0026#34;, \u0026#34;.webp\u0026#34;} def is_light_background_pixel(r: int, g: int, b: int) -\u0026gt; bool: brightness = (r + g + b) / 3 spread = max(r, g, b) - min(r, g, b) return brightness \u0026gt;= 170 and spread \u0026lt;= 35 def to_pil_image(image_obj) -\u0026gt; Image.Image: if isinstance(image_obj, Image.Image): return image_obj pil_image = getattr(image_obj, \u0026#34;_pil_image\u0026#34;, None) if isinstance(pil_image, Image.Image): return pil_image as_pil = getattr(image_obj, \u0026#34;pil_image\u0026#34;, None) if isinstance(as_pil, Image.Image): return as_pil raise TypeError(f\u0026#34;Unsupported image object type: {type(image_obj)!r}\u0026#34;) def make_transparent_from_borders(image: Image.Image) -\u0026gt; Image.Image: rgba = image.convert(\u0026#34;RGBA\u0026#34;) width, height = rgba.size pixels = rgba.load() visited: set[tuple[int, int]] = set() queue: deque[tuple[int, int]] = deque() def push_if_bg(x: int, y: int) -\u0026gt; None: if (x, y) in visited: return r, g, b, _ = pixels[x, y] if is_light_background_pixel(r, g, b): visited.add((x, y)) queue.append((x, y)) for x in range(width): push_if_bg(x, 0) push_if_bg(x, height - 1) for y in range(height): push_if_bg(0, y) push_if_bg(width - 1, y) while queue: x, y = queue.popleft() for nx, ny in ((x - 1, y), (x + 1, y), (x, y - 1), (x, y + 1)): if 0 \u0026lt;= nx \u0026lt; width and 0 \u0026lt;= ny \u0026lt; height: push_if_bg(nx, ny) for x, y in visited: pixels[x, y] = (0, 0, 0, 0) return rgba def remove_small_components(image: Image.Image, min_component_pixels: int) -\u0026gt; Image.Image: if min_component_pixels \u0026lt;= 0: return image rgba = image.convert(\u0026#34;RGBA\u0026#34;) alpha = rgba.getchannel(\u0026#34;A\u0026#34;) width, height = rgba.size alpha_pixels = alpha.load() rgba_pixels = rgba.load() visited: set[tuple[int, int]] = set() for y in range(height): for x in range(width): if alpha_pixels[x, y] == 0 or (x, y) in visited: continue queue: deque[tuple[int, int]] = deque([(x, y)]) visited.add((x, y)) component: list[tuple[int, int]] = [] while queue: cx, cy = queue.popleft() component.append((cx, cy)) for nx, ny in ((cx - 1, cy), (cx + 1, cy), (cx, cy - 1), (cx, cy + 1)): if 0 \u0026lt;= nx \u0026lt; width and 0 \u0026lt;= ny \u0026lt; height: if alpha_pixels[nx, ny] == 0 or (nx, ny) in visited: continue visited.add((nx, ny)) queue.append((nx, ny)) if len(component) \u0026lt; min_component_pixels: for px, py in component: r, g, b, _ = rgba_pixels[px, py] rgba_pixels[px, py] = (r, g, b, 0) return rgba def normalize_product_image( image: Image.Image, canvas_size: int, target_width: int, ) -\u0026gt; Image.Image: rgba = image.convert(\u0026#34;RGBA\u0026#34;) bbox = rgba.getchannel(\u0026#34;A\u0026#34;).getbbox() if bbox is None: return Image.new(\u0026#34;RGBA\u0026#34;, (canvas_size, canvas_size), (0, 0, 0, 0)) subject = rgba.crop(bbox) if subject.height \u0026gt; subject.width: subject = subject.rotate(-90, expand=True, resample=Image.Resampling.BICUBIC) rotated_bbox = subject.getchannel(\u0026#34;A\u0026#34;).getbbox() if rotated_bbox is not None: subject = subject.crop(rotated_bbox) scale = target_width / subject.width subject = subject.resize( (target_width, max(1, int(round(subject.height * scale)))), Image.Resampling.LANCZOS, ) canvas = Image.new(\u0026#34;RGBA\u0026#34;, (canvas_size, canvas_size), (0, 0, 0, 0)) offset_x = (canvas_size - subject.width) // 2 offset_y = (canvas_size - subject.height) // 2 canvas.alpha_composite(subject, (offset_x, offset_y)) return canvas def finalize_product_image( image: Image.Image, canvas_size: int, target_width: int, min_component_pixels: int, ) -\u0026gt; Image.Image: transparent = make_transparent_from_borders(image) cleaned = remove_small_components(transparent, min_component_pixels) return normalize_product_image(cleaned, canvas_size=canvas_size, target_width=target_width) def save_first_image_part( response, dst: Path, canvas_size: int, target_width: int, min_component_pixels: int, ) -\u0026gt; None: parts = getattr(response, \u0026#34;parts\u0026#34;, None) if parts is None and getattr(response, \u0026#34;candidates\u0026#34;, None): parts = response.candidates[0].content.parts if not parts: raise RuntimeError(\u0026#34;Model returned no content parts.\u0026#34;) for part in parts: inline_data = getattr(part, \u0026#34;inline_data\u0026#34;, None) if inline_data is None and isinstance(part, dict): inline_data = part.get(\u0026#34;inline_data\u0026#34;) if inline_data is None: continue if hasattr(part, \u0026#34;as_image\u0026#34;): image = to_pil_image(part.as_image()) dst.parent.mkdir(parents=True, exist_ok=True) finalize_product_image( image, canvas_size=canvas_size, target_width=target_width, min_component_pixels=min_component_pixels, ).save(dst) return data = getattr(inline_data, \u0026#34;data\u0026#34;, None) if data: dst.parent.mkdir(parents=True, exist_ok=True) with open(dst, \u0026#34;wb\u0026#34;) as handle: handle.write(data) with Image.open(dst) as image: processed = finalize_product_image( image, canvas_size=canvas_size, target_width=target_width, min_component_pixels=min_component_pixels, ) processed.save(dst.with_suffix(\u0026#34;.png\u0026#34;)) if dst.suffix.lower() != \u0026#34;.png\u0026#34;: dst.unlink(missing_ok=True) return raise RuntimeError(\u0026#34;Model returned text only and no edited image.\u0026#34;) def process_image( src: Path, dst: Path, client, model: str, canvas_size: int, target_width: int, min_component_pixels: int, ) -\u0026gt; None: with Image.open(src).convert(\u0026#34;RGBA\u0026#34;) as image: response = client.models.generate_content( model=model, contents=[PROMPT, image], ) save_first_image_part( response, dst, canvas_size=canvas_size, target_width=target_width, min_component_pixels=min_component_pixels, ) def parse_args() -\u0026gt; argparse.Namespace: parser = argparse.ArgumentParser( description=\u0026#34;Cut out product images with Gemini and normalize them to square transparent PNGs.\u0026#34; ) parser.add_argument(\u0026#34;input_dir\u0026#34;, type=Path) parser.add_argument(\u0026#34;output_dir\u0026#34;, type=Path) parser.add_argument(\u0026#34;--model\u0026#34;, default=\u0026#34;gemini-2.5-flash-image\u0026#34;) parser.add_argument(\u0026#34;--canvas-size\u0026#34;, type=int, default=DEFAULT_CANVAS_SIZE) parser.add_argument(\u0026#34;--target-width\u0026#34;, type=int, default=DEFAULT_TARGET_WIDTH) parser.add_argument(\u0026#34;--min-component-pixels\u0026#34;, type=int, default=DEFAULT_MIN_COMPONENT_PIXELS) parser.add_argument(\u0026#34;--overwrite\u0026#34;, action=\u0026#34;store_true\u0026#34;) return parser.parse_args() def main() -\u0026gt; None: args = parse_args() api_key = os.environ.get(\u0026#34;GEMINI_API_KEY\u0026#34;) if not api_key: raise SystemExit(\u0026#34;Missing GEMINI_API_KEY environment variable.\u0026#34;) if not args.input_dir.is_dir(): raise SystemExit(f\u0026#34;Input directory does not exist: {args.input_dir}\u0026#34;) if args.canvas_size \u0026lt;= 0: raise SystemExit(\u0026#34;--canvas-size must be positive.\u0026#34;) if args.target_width \u0026lt;= 0 or args.target_width \u0026gt; args.canvas_size: raise SystemExit(\u0026#34;--target-width must be positive and no larger than --canvas-size.\u0026#34;) if args.min_component_pixels \u0026lt; 0: raise SystemExit(\u0026#34;--min-component-pixels must be \u0026gt;= 0.\u0026#34;) args.output_dir.mkdir(parents=True, exist_ok=True) client = genai.Client(api_key=api_key) for src in sorted(args.input_dir.iterdir()): if not src.is_file() or src.suffix.lower() not in SUPPORTED_EXTENSIONS: continue dst = args.output_dir / f\u0026#34;{src.stem}.png\u0026#34; if dst.exists() and not args.overwrite: print(f\u0026#34;skip {dst}\u0026#34;) continue process_image( src, dst, client, args.model, canvas_size=args.canvas_size, target_width=args.target_width, min_component_pixels=args.min_component_pixels, ) print(dst) if __name__ == \u0026#34;__main__\u0026#34;: main() 添付ファイルをダウンロード: product-cutout-normalize.7z\n","date":"2026-04-09T21:43:50+08:00","permalink":"https://www.knightli.com/ja/2026/04/09/product-cutout-normalize-agent-skill-guide/","title":"eコマース商品画像の切り抜きと標準化されたエージェントスキルを共有する"},{"content":"この記事では、実用的な Python スクリプトを使用して、Google の Nano Banana 画像編集機能を呼び出して商品画像を切り出す方法を示します。\nこの現在の実装の目標は明確です。\nカタログから製品画像を読み取る Google 画像モデルを呼び出して背景の削除を実行します。 返された画像に対してローカルの透明な背景のクリーニングを再度実行します 最終出力は透明な下部 PNG 白い背景の製品画像、ヘッドフォンの画像、および配線図面のバッチがすでにあり、電子商取引で使用できる透明な背景画像をすばやく生成したい場合、この方法は非常に簡単です。\nこのコードは何をするのか\rこのスクリプトは主に 4 つの部分に分かれています。\n「背景を削除し、被写体を保持し、影を追加しない」ことをモデルに知らせるプロンプト ワードを定義します。 google-genai の画像生成インターフェイスを呼び出します。 モデル応答から画像結果を抽出する 次に、ローカル ロジックを使用してエッジの明るい背景を透明に変換し、残留エッジを減らします。 つまり、単にモデルに画像を投げただけでは終わりではなく、「モデル編集＋ローカル後処理」を繋ぎ合わせて完成するのです。\n走る前の準備\r最初に依存関係をインストールします。\n1 .\\.venv\\Scripts\\python.exe -m pip install google-genai pillow GEMINI_API_KEYの取得方法\rGEMINI_API_KEY は、Gemini API を呼び出すときに使用されるキーです。 Google の公式クイックスタートによると、キーをまだ持っていない場合は、Google AI Studio で直接作成できます。\n入手手順は以下の通りです。\nGoogle AIスタジオを開きます。 Google アカウントにサインインします。 Get API key または API keys ページを見つけます。 新しい API キーを作成します。 生成されたキーをコピーします。 スクリプトが読み取ることができるように、これをローカル環境変数に構成します。 ページ上に使用可能なプロジェクトがない場合は、通常、最初にプロジェクトの初期化を完了してから、[API キー] ページに戻ってキーを作成する必要があります。\nキーを取得したら、環境変数を構成します。\n1 $env:GEMINI_API_KEY=\u0026#34;your_api_key\u0026#34; cmd を使用している場合は、次のように記述できます。\n1 set GEMINI_API_KEY=your_api_key GEMINI_API_KEY と GOOGLE_API_KEY を同時に設定した場合、実際の動作では通常 GOOGLE_API_KEY が最初に読み込まれるため、混乱を避けるために 1 つだけを保持することをお勧めします。\nディレクトリ構造の例\rスクリプトは 2 つのパラメータを受け取ります。\ninput_dir: 画像ディレクトリに入る output_dir: 出力画像ディレクトリ 例えば：\n1 2 3 4 5 images/ product1.jpg product2.png output/ 走り方\rスクリプトファイル名がcutout.pyで、実行方法が次のとおりであるとします。\n1 .\\.venv\\Scripts\\python.exe .\\cutout.py .\\images .\\output モデルを変更したい場合は、パラメーターを明示的に渡すこともできます。\n1 .\\.venv\\Scripts\\python.exe .\\cutout.py .\\images .\\output --model gemini-2.5-flash-image スクリプトは、入力ディレクトリ内のファイルを次の形式でループします。\n.jpg .jpeg .png .webp 処理が完了すると、同じ名前の透過的な PNG ファイルが出力ディレクトリに生成されます。\nコア呼び出しプロセス\r実際に Google Nano Banana を呼び出すキーコードは次のとおりです。\n1 2 3 4 response = client.models.generate_content( model=model, contents=[PROMPT, image], ) ここでは 2 つのコンテンツが渡されます。\nテキスト プロンプトの単語 PROMPT ワンピース PIL.Image プロンプトの内容は、製品画像全体の背景を削除し、本体のみを残し、いくつかの点を強調するようモデルに依頼することです。\n完全な製品を保管する 細いワイヤーとケーブルの詳細を保持 内部の空洞と環状領域をきれいにします 新しいオブジェクトを追加しないでください 影を追加しないでください この種のプロンプトワードは、カットアウトの品質、特にヘッドフォンケーブル、透明なエッジ、中空領域などの細部に大きな影響を与えます。\nなぜローカルで後処理を行う必要があるのでしょうか?\rモデルが結果を返した後、スクリプトは直接保存されませんが、make_transparent_from_borders(image) が再度実行されます。\nこのステップの考え方は次のとおりです。\n画像の周囲のエッジから始まる明るい背景ピクセルを見つけます 幅優先検索を使用して、接続されているすべての明るい色の領域をマークします。 最後に、これらの領域を透明に変更します。 これを行う利点は、残っている白いエッジ、明るい灰色の背景、および不十分にきれいなエッジ領域をさらに除去できることです。\n「背景かどうか」の判断条件は以下の通りです。\n1 2 3 4 def is_light_background_pixel(r: int, g: int, b: int) -\u0026gt; bool: brightness = (r + g + b) / 3 spread = max(r, g, b) - min(r, g, b) return brightness \u0026gt;= 170 and spread \u0026lt;= 35 簡単な理解は次のとおりです。\n全体的に色が明るいので 3 つの RGB チャネルの差が大きすぎることはありません 商品画像の背景が白地やライトグレー地、単色に近いものを加工する場合に適しています。\n完全なソースコード\r現在の完全なソース コードは、直接の再利用や二次的な変更を容易にするために以下に保持されています。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 from __future__ import annotations import argparse import os from pathlib import Path from collections import deque from PIL import Image try: from google import genai except ImportError as exc: # pragma: no cover raise SystemExit( \u0026#34;Missing dependency: google-genai. Install it with \u0026#34; r\u0026#34;\u0026#39;.\\.venv\\Scripts\\python.exe -m pip install google-genai\u0026#39;.\u0026#34; ) from exc PROMPT = ( \u0026#34;Remove the entire background from this product photo and return only the product \u0026#34; \u0026#34;on a fully transparent background as a PNG. Keep the full product intact, preserve \u0026#34; \u0026#34;thin cable details, clean the inner loops and holes, and do not add any new objects \u0026#34; \u0026#34;or shadows.\u0026#34; ) def is_light_background_pixel(r: int, g: int, b: int) -\u0026gt; bool: brightness = (r + g + b) / 3 spread = max(r, g, b) - min(r, g, b) return brightness \u0026gt;= 170 and spread \u0026lt;= 35 def to_pil_image(image_obj) -\u0026gt; Image.Image: if isinstance(image_obj, Image.Image): return image_obj pil_image = getattr(image_obj, \u0026#34;_pil_image\u0026#34;, None) if isinstance(pil_image, Image.Image): return pil_image as_pil = getattr(image_obj, \u0026#34;pil_image\u0026#34;, None) if isinstance(as_pil, Image.Image): return as_pil raise TypeError(f\u0026#34;Unsupported image object type: {type(image_obj)!r}\u0026#34;) def make_transparent_from_borders(image: Image.Image) -\u0026gt; Image.Image: rgba = image.convert(\u0026#34;RGBA\u0026#34;) width, height = rgba.size pixels = rgba.load() visited: set[tuple[int, int]] = set() queue: deque[tuple[int, int]] = deque() def push_if_bg(x: int, y: int) -\u0026gt; None: if (x, y) in visited: return r, g, b, _ = pixels[x, y] if is_light_background_pixel(r, g, b): visited.add((x, y)) queue.append((x, y)) for x in range(width): push_if_bg(x, 0) push_if_bg(x, height - 1) for y in range(height): push_if_bg(0, y) push_if_bg(width - 1, y) while queue: x, y = queue.popleft() for nx, ny in ((x - 1, y), (x + 1, y), (x, y - 1), (x, y + 1)): if 0 \u0026lt;= nx \u0026lt; width and 0 \u0026lt;= ny \u0026lt; height: push_if_bg(nx, ny) for x, y in visited: pixels[x, y] = (0, 0, 0, 0) return rgba def save_first_image_part(response, dst: Path) -\u0026gt; None: parts = getattr(response, \u0026#34;parts\u0026#34;, None) if parts is None and getattr(response, \u0026#34;candidates\u0026#34;, None): parts = response.candidates[0].content.parts if not parts: raise RuntimeError(\u0026#34;Model returned no content parts.\u0026#34;) for part in parts: inline_data = getattr(part, \u0026#34;inline_data\u0026#34;, None) if inline_data is None and isinstance(part, dict): inline_data = part.get(\u0026#34;inline_data\u0026#34;) if inline_data is None: continue if hasattr(part, \u0026#34;as_image\u0026#34;): image = to_pil_image(part.as_image()) dst.parent.mkdir(parents=True, exist_ok=True) make_transparent_from_borders(image).save(dst) return data = getattr(inline_data, \u0026#34;data\u0026#34;, None) mime_type = getattr(inline_data, \u0026#34;mime_type\u0026#34;, \u0026#34;\u0026#34;) if data: dst.parent.mkdir(parents=True, exist_ok=True) with open(dst, \u0026#34;wb\u0026#34;) as handle: handle.write(data) with Image.open(dst) as img: processed = make_transparent_from_borders(img) processed.save(dst.with_suffix(\u0026#34;.png\u0026#34;)) if dst.suffix.lower() != \u0026#34;.png\u0026#34;: dst.unlink(missing_ok=True) return raise RuntimeError(\u0026#34;Model returned text only and no edited image.\u0026#34;) def process_image(src: Path, dst: Path, client, model: str) -\u0026gt; None: with Image.open(src).convert(\u0026#34;RGBA\u0026#34;) as image: response = client.models.generate_content( model=model, contents=[PROMPT, image], ) save_first_image_part(response, dst) def main() -\u0026gt; None: parser = argparse.ArgumentParser(description=\u0026#34;Use Nano Banana / Gemini image editing to cut out product images.\u0026#34;) parser.add_argument(\u0026#34;input_dir\u0026#34;, type=Path) parser.add_argument(\u0026#34;output_dir\u0026#34;, type=Path) parser.add_argument(\u0026#34;--model\u0026#34;, default=\u0026#34;gemini-2.5-flash-image\u0026#34;) args = parser.parse_args() api_key = os.environ.get(\u0026#34;GEMINI_API_KEY\u0026#34;) if not api_key: raise SystemExit(\u0026#34;Missing GEMINI_API_KEY environment variable.\u0026#34;) client = genai.Client(api_key=api_key) exts = {\u0026#34;.jpg\u0026#34;, \u0026#34;.jpeg\u0026#34;, \u0026#34;.png\u0026#34;, \u0026#34;.webp\u0026#34;} for src in sorted(args.input_dir.iterdir()): if not src.is_file() or src.suffix.lower() not in exts: continue dst = args.output_dir / f\u0026#34;{src.stem}.png\u0026#34; process_image(src, dst, client, args.model) print(dst) if __name__ == \u0026#34;__main__\u0026#34;: main() 最適化を続けるのに適した場所\rこのスクリプトを大量生産に引き続き使用する予定がある場合は、後でこれらの機能を追加し続けることができます。\n単一の画像エラーが報告された後にバッチ全体が中断されるのを避けるために、失敗の再試行が追加されました。 ログを記録して、処理に失敗した画像を特定しやすくします さまざまなバックグラウンドしきい値に合わせて構成可能 サブディレクトリの再帰的スキャンをサポート 元の画像と結果画像の比較プレビューを追加しました まとめ\r「Google Nano Banana を呼び出して画像を切り出す方法」をすぐに理解したい場合は、実際には 3 つの主要な手順があります。\ngoogle-genai および Pillow をインストールする GEMINI_API_KEY を設定します client.models.generate_content() を使用してプロンプトの言葉と画像を渡します このコードの価値は、モデルを呼び出すだけでなく、製品画像の切り抜きタスクで直接使用するのに適した透明な背景の後処理も追加することです。\n","date":"2026-04-09T20:10:48+08:00","permalink":"https://www.knightli.com/ja/2026/04/09/google-nano-banana-cutout-guide/","title":"Google Nano Bananaを呼び出して画像を切り出す方法"},{"content":"普段 Ollama を使用してローカル モデルを実行している場合は、クラウド モデルを簡単に理解できるはずです。\n主要な相違点は 1 つだけです。\nローカル モデルはユーザーのコンピューター上で推論され、クラウド モデルは Ollama のクラウド上で推論され、結果が返されます。\nクラウドモデルとは何ですか\rOllama クラウド モデルは、Ollama の呼び出し方法を保持しますが、コンピューティングの場所をローカルからクラウドに変更します。\nこれを行うことの利点は次のとおりです。\nローカルハードウェアへの負担が軽減される ローカルマシンでは実行できない大規模なモデルを使いやすくする 使い慣れた Ollama ワークフローを引き続き使用できます 現地モデルとの違い\r对比项 本地模型 云模型 运行位置 本机 云端 硬件要求 高 低 延迟 更低 受网络影响 隐私性 更强 请求会发送到云端 プライバシー、低遅延、オフライン使用を重視する場合は、ローカル モデルの方が適しています。\nローカルのハードウェアでは十分ではないが、より大規模なモデルを体験したい場合は、クラウド モデルの方が便利です。\nクラウドモデルを特定する方法\r現在の Ollama クラウド モデルには通常、サフィックス -cloud が付いています。次に例を示します。\n1 gpt-oss:120b-cloud 利用可能なモデルのリストは変更される可能性があります。Ollamaの公式ページを参照してください。\n使用方法\rまずログインしてください:\n1 ollama signin ログイン後、クラウド モデルを直接実行します。\n1 ollama run gpt-oss:120b-cloud コードから呼び出している場合は、API キーを構成することもできます。\n1 export OLLAMA_API_KEY=your_api_key Python の例:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 import os from ollama import Client client = Client( host=\u0026#34;https://ollama.com\u0026#34;, headers={\u0026#34;Authorization\u0026#34;: \u0026#34;Bearer \u0026#34; + os.environ[\u0026#34;OLLAMA_API_KEY\u0026#34;]}, ) messages = [ {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;为什么天空是蓝色的？\u0026#34;} ] for part in client.chat(\u0026#34;gpt-oss:120b-cloud\u0026#34;, messages=messages, stream=True): print(part[\u0026#34;message\u0026#34;][\u0026#34;content\u0026#34;], end=\u0026#34;\u0026#34;, flush=True) まとめ\rOllama クラウド モデルは、次の一文で理解できます。\nコマンドは基本的に同じままですが、モデルはローカルで実行されなくなります。\nコンピューターで大規模なモデルを実行できないが、引き続き Ollama を使用してモデルを呼び出したい場合、クラウド モデルは非常に簡単なソリューションです。\n","date":"2026-04-09T18:42:32+08:00","permalink":"https://www.knightli.com/ja/2026/04/09/ollama-cloud-models-guide/","title":"Ollama クラウド モデルとは何か、そしてその使用方法"},{"content":"Windows タスク マネージャーを開くと、[プロセス] または [パフォーマンス] ページのデータがスタックしているように見え、CPU、メモリ、ディスク、またはネットワークの値が長期間変更されていないことがわかることがあります。一見するとシステムの異常のように見えますが、実際に実行されているプログラム、ネットワーク伝送、リソースの使用状況は正常に変化しています。\nこの状況は通常、システムが実際に停止したことを意味するのではなく、タスク マネージャーの更新頻度が「一時停止」に変更されたことを意味します。\n現象\r一般的な症状には次のものがあります。\n「プロセス」ページの CPU、メモリ、その他のデータがジャンプしなくなりました 「パフォーマンス」ページのカーブが長期間更新されない 明らかにプログラムが実行されていますが、タスク マネージャーは非アクティブになっているように見えます。 問題が発生した場合のインターフェイスの例を次に示します。\n理由\rタスク マネージャーは、「更新速度」の調整をサポートしており、高速、標準、低速、または一時停止に直接設定できます。\nこれを「一時停止」に設定すると、インターフェイス上のさまざまな統計情報が更新されなくなるため、CPU、メモリ、またはネットワーク情報がすべて停止したように見えます。\n下の図に示すように、このオプションは通常、タスク マネージャーの上部メニューの [表示] にあります。\n","date":"2026-04-09T18:15:53+08:00","permalink":"https://www.knightli.com/ja/2026/04/09/windows-task-manager-data-paused/","title":"Windows タスク マネージャーのデータは一時停止され、更新されません。通常、更新速度は一時停止に設定されます。"},{"content":"モデルの公式 Ollama ライブラリに既製バージョンがない場合、または Hugging Face で特定の GGUF ファイルを使用したい場合は、手動でダウンロードして Ollama にインポートできます。\nステップ 1: Hugging Face から GGUF ファイルをダウンロードする\rまず、Hugging Face で対象モデルに対応する GGUF ファイルを見つけます。次のような複数の量子化バージョンが表示されるのが一般的です。\nQ4_K_M Q5_K_M Q8_0 どのバージョンを選択するかは、ビデオ メモリ、メモリ、速度と品質の選択によって異なります。ダウンロード後、.gguf ファイルを固定ディレクトリに置き、後で Modelfile で直接参照します。\nステップ 2: モデルファイルを作成する\rモデル ファイルと同じディレクトリに新しい Modelfile を作成します。最も基本的な書き方は次のとおりです。\n1 FROM ./model.gguf ファイル名が異なる場合は、次のように実際のファイル名に変更します。\n1 FROM ./gemma-3-12b-it-q4_k_m.gguf 最初に実行したいだけの場合は、通常、FROM 行で十分です。\nステップ 3: Ollama にインポートする\r次に、以下を実行します。\n1 ollama create myModelName -f Modelfile myModelName は、Ollama で使用するローカル モデル名です。 -f Modelfile は、この構成ファイルからモデルを作成することを意味します 作成が成功すると、この GGUF ファイルは直接呼び出すことができるローカル モデルになります。\nステップ 4: モデルを実行する\r作成後に直接実行します。\n1 ollama run myModelName 以降の使い方は基本的にollama pullのモデルと同じです。\n既存のモデルのモデルファイルを表示する方法\rModelfile の書き方がわからない場合は、既存のモデルの構成を直接表示できます。\n1 ollama show --modelfile llama3.2 このコマンドは、参照に適した llama3.2 の Modelfile コンテンツを出力します。\nFROMの書き方 テンプレートとシステム プロンプトはどのように構成されていますか? パラメータの宣言方法 このルートを使用するのが適切なのはどのような場合ですか?\r次のシナリオは、Hugging Face からの手動インポートに適しています。\n必要なモデルは、公式 Ollama ライブラリではまだ利用できません。 特定の量子化バージョンを使用したい場合 GGUF ファイルを手動でダウンロードしました モデルのパッケージ化方法をよりきめ細かく制御したい 公式ライブラリに既製のバージョンがある場合は、通常、pull を直接使用する方が簡単です。ただし、特定の量子化やカスタム パッケージングが必要な場合は、GGUF + Modelfile の方がより柔軟です。\n共通の注意点\rFROM の後のパスは、実際の .gguf ファイルの場所と一致している必要があります。 ファイル名にスペースや特殊文字が含まれている場合は、最初に簡単な名前に変更することをお勧めします。 GGUF の量子化バージョンが異なると、メモリと速度に大きな影響を与えます。インポートが成功しても、操作がスムーズに行われるとは限りません。 モデルがチャット モデルの場合、効果がより安定するように、後でその形式に応じてプロンプト テンプレートを調整する必要があります。 結論は\rHugging Face から GGUF ファイルをダウンロードして Ollama にインポートするのは複雑ではありません。モデル ファイルを準備し、使用可能な最小限の Modelfile を書き込み、その後 ollama create を実行してサードパーティの GGUF モデルを Ollama に接続します。\n","date":"2026-04-09T11:00:07+08:00","permalink":"https://www.knightli.com/ja/2026/04/09/import-huggingface-gguf-into-ollama/","title":"Hugging Face から GGUF モデルをダウンロードし、Ollama にインポートします。"},{"content":"ollama pull model_name:tag 一部の地域ではダウンロード速度が非常に遅くなり、プロセスが安定しません。\n大きなモデルのダウンロード中に繰り返し中断が発生し、TLS handshake timeout または unexpected EOF のエラー メッセージが表示される場合は、おそらく registry.ollama.ai 自体だけでなく、その後にジャンプされる実際のダウンロード リンクに問題があると考えられます。\nこの記事では、シンプルかつ直接的なトラブルシューティングのアイデアを記録します。最初にモデル ファイルの実際のダウンロード アドレスを取得し、次に最終的なトラフィックがどこに落ちるかを確認し、最後に主要なドメイン名に対してのみネットワークの最適化を実行します。\nモデルファイルのダウンロードアドレスを取得する\r次のプロジェクトを使用して、Ollama モデルに対応するマニフェストと BLOB のダウンロード アドレスを直接抽出できます。\nhttps://github.com/Gholamrezadar/ollama-direct-downloader\ngemma4:latest を例として、次のようなリンクを抽出できます。\nマニフェストアドレス\r1 https://registry.ollama.ai/v2/library/gemma4/manifests/latest BLOB アドレス\r1 2 3 4 https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11 https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2 https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3 すぐに確認したいだけの場合は、curl を直接使用してマニフェストと BLOB をダウンロードすることもできます。\n1 2 3 4 curl -L \u0026#34;https://registry.ollama.ai/v2/library/gemma4/manifests/latest\u0026#34; -o \u0026#34;latest\u0026#34; curl -L \u0026#34;https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11\u0026#34; -o \u0026#34;sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11\u0026#34; curl -L \u0026#34;https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a\u0026#34; -o \u0026#34;sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a\u0026#34; curl -L \u0026#34;https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2\u0026#34; -o \u0026#34;sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2\u0026#34; ジャンプ後の実際のダウンロード アドレス\rwget を使用して BLOB の 1 つをダウンロードしてみてください。リクエストは registry.ollama.ai にとどまらず、引き続き Cloudflare R2 オブジェクト ストレージ アドレスにジャンプしていることがわかります。\n1 2 3 4 5 6 7 8 9 10 11 wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a --2026-04-09 09:22:04-- https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ... Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected. HTTP request sent, awaiting response... 307 Temporary Redirect Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following] --2026-04-09 09:22:05-- https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1 Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 9608338848 (8.9G) [application/octet-stream] ログからいくつかの重要な情報を確認できます。\nregistry.ollama.ai が 307 Temporary Redirect を返しました 最終的なダウンロード アドレスは *.r2.cloudflarestorage.com になります。 大きなファイルの送信を実際に実行しているのは、実際にはその背後にあるオブジェクト ストレージ ドメイン名です。 この手順は、プロキシまたは転送ルールが registry.ollama.ai のみをカバーし、*.r2.cloudflarestorage.com を処理しない場合、ダウンロードが依然として遅くなるか、繰り返し中断される可能性があることを意味するため、重要です。\nネットワーク設定を調整する\r実際のダウンロード リンクを確認すると、トラブルシューティングの方向性がより明確になります。\nプロキシ、オフロード、またはカスタム DNS を使用している場合は、最初に次のことを確認することをお勧めします。\nregistry.ollama.ai と *.r2.cloudflarestorage.com は同じ安定したルートをたどりましたか? プロキシ ルールは前者のみをカバーし、後者は除外しますか? 現在のエクスポートは、数ギガバイトから数十ギガバイトまでの大きなファイルを継続的にダウンロードするのに適していますか? この種の問題の鍵は、「公式サイトが開設できるかどうか」ではなく、「ジャンプ後のオブジェクトストレージリンクが安定し、長時間送信し続けられるかどうか」である。多くの場合、本当に最適化する必要があるのは、以前のレジストリ ドメイン名ではなく、Cloudflare R2 レイヤーです。\n調整前と調整後の比較\r以下は、実際に gemma4:31b-it-q8_0 をダウンロードした場合のパフォーマンスです。\n調整前はダウンロード速度が遅く、途中でエラーが報告されていました。\n1 2 3 4 PS C:\\Users\\knightli\u0026gt; ollama run gemma4:31b-it-q8_0 pulling manifest pulling a0feadb736f5: 38% ▕██████████████████████ ▏ 12 GB/ 33 GB 1.2 MB/s 4h40m Error: max retries exceeded: unexpected EOF 調整後、同じモデルを再度ダウンロードすると、速度と安定性が大幅に向上しました。\n1 2 3 PS C:\\Users\\knightli\u0026gt; ollama run gemma4:31b-it-q8_0 pulling manifest pulling a0feadb736f5: 46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB 8.5 MB/s 35m23s これは、すべてのネットワーク環境で同じ結果が得られるという意味ではありませんが、少なくとも 1 つの点を示しています。ボトルネックは Ollama クライアント自体ではなく、実際の大きなファイルのダウンロード リンクにある可能性が高いということです。\n","date":"2026-04-09T10:42:39+08:00","permalink":"https://www.knightli.com/ja/2026/04/09/ollama-download-slow-troubleshooting/","title":"Ollama ダウンロード モデルのプル速度が遅い場合のトラブルシューティングと解決策"},{"content":"イベントの背景\r2026 年 4 月 4 日、Anthropic は、OpenClaw などのサードパーティ ツールに対するクロードのサブスクリプションの対象を打ち切ると発表しました。\nユーザー レベルへの直接的な影響は、もともとサブスクリプション パスに依存してクロードにアクセスしていたサードパーティ プロセスを、他のアクセス方法に変更するか、他のモデルに切り替える必要があることです。\nタイムライン（2026年1月から4月）\r2026年1月\r公開報道によると、Anthropic は、当時 Clawdbot として知られていたこのプロジェクトに対し、発音がクロードに近いことから名前の変更を求めたという。\n同じ段階で、サードパーティがサブスクリプション認証情報を介して通話できる機能が限られているというフィードバックがコミュニティから出始めました。\n2026年2月\r関連する制限はサービス規約に記載されており、サブスクリプションとサードパーティの自動呼び出しとの境界がさらに明確になります。\n同月、OpenClaw は v4.0 をリリースし、基礎となるアーキテクチャがプラグイン可能なモデル バックエンドに変更されました。つまり、モデルは単一の固定された入り口ではなくなり、複数のモデルプロバイダーの間で切り替えることができます。\n2026年3月\rAnthropic は、リモート タスクの実行やデスクトップ操作などの機能をカバーする、Claude Dispatch と Computer Use をリリースします。\nOpenClaw は今後のアップデートでも互換性レイヤーを推進し、異なるモデルの認証方法、ツール呼び出し形式、戻り構造の違いを統一し、モデルを切り替える際の移行コストを削減します。\n公開レポートでは、OpenClaw チームが 3 月下旬に Anthropic と連絡を取ったとも述べられていましたが、最終的な戦略的方向性は変更されませんでした。\n2026 年 4 月 4 日\rAnthropic は、サードパーティ ツールのサブスクリプション適用範囲の打ち切りを正式に実装します。\nこれは、過去数か月間に行われた戦略的調整の実施段階を示します。\n2026 年 4 月 5 日\rOpenClaw は v4.5 をリリースします。主なアクションには次のようなものがあります。\nブートストラッププロセス中にモデルエントリの優先順位を調整する GPT-5.4 などの代替モデル パスにアクセスする タスクのプロセスとインタラクティブなエクスペリエンスに適応し続ける リリース時期から判断すると、OpenClaw のスイッチング機能は完全に一時的なビルドではなく、2 月以降のマルチモデル アーキテクチャの変革に基づいています。\nプロセスにおける 2 つの平行した方向\rタイムラインを見ると、両当事者は同じ期間に異なる方向に前進しました。\nAnthropic: サブスクリプションの境界を厳格化し、公式の製品機能の統合を促進します。 OpenClaw: モデルの置換可能性を強化し、モデル間の互換性を向上させます。 この 2 つのルートは矛盾するものではありませんが、「エントリーの所有権」と「ユーザーのワークフローの登録位置」という点で競合関係が生じます。\n現状（2026年4月現在）\r公開されている情報に基づいて、次の事実が確認できます。\nサブスクリプションオーバーライドのカットオフが実行されました OpenClaw はメジャー モデル パスの切り替えを完了し、バージョンの反復を維持しました ユーザーが大きな変化を感じるかどうかは、元のワークフローが単一モデルの機能にどの程度依存しているかによって決まります。 経過観察のポイント\r次に注目すべきは、その事件そのものではなく、次の 3 つの点です。\nサブスクリプション プランと API 呼び出しの間の境界は今後も改善されていくのでしょうか? 安定性、コスト、エクスペリエンスの観点からマルチモデルエージェントの長期的なパフォーマンスを実現 ユーザーのワークフローは最終的にモデル層、ツール層、あるいはその 2 つの間のハイブリッド層に落ち着きますか? ","date":"2026-04-08T19:48:42+08:00","permalink":"https://www.knightli.com/ja/2026/04/08/anthropic-openclaw-timeline-2026-04/","title":"Anthropic による OpenClaw 禁止の完全なタイムライン"},{"content":"極端な試み: Raspberry Pi 5（8GB RAM） で Gemma 4 を実行します。目標は、大規模なモデル バージョンではなく、E2B の最小バージョンです。\n結論から始めましょう。実行して使用することはできますが、対話頻度の低いシナリオに適しており、リアルタイム要件の高い対話エクスペリエンスには適していません。\nテスト環境\rデバイス: Raspberry Pi 5 (4コアCPU、8GB RAM) システム: Ubuntu サーバー (グラフィカル インターフェイスなし) アクセス方法：SSH モデルの実行方法: LM Studio CLI (コマンドラインモードのみ) モデル：Gemma 4 E2B (約4.5GB) ステップ 1: LM Studio CLI をインストールして起動する\rLM Studio の CLI バージョンをインストールし、サービスを開始して、使用可能なコマンドを確認します。\nこれは純粋なコマンド ライン環境であるため、このコマンド ラインのみの展開方法は Raspberry Pi に非常に適しています。\nステップ 2: モデルのストレージを SSD に切り替える\rSDカードの頻繁な読み書きを避けるため、モデルのダウンロードディレクトリを外付けSSDに変更しました。\nSSD を Raspberry Pi 5 に接続する体験は、明らかに以前のモデルよりも実用的です。長期的なローカル モデルでは、最初に SSD を使用することをお勧めします。\nステップ 3: Gemma 4 E2B をダウンロードしてロードする\rダウンロードが完了すると、モデルをメモリに正常にロードできるようになります。\n公式情報によると、Gemma 4 シリーズには次の機能があります。\nエージェントシナリオのツール呼び出し機能 (関数呼び出し) マルチモーダル機能 (画像/ビデオを含む。小型モデルには音声関連機能もある) 128K コンテキスト ウィンドウ Apache 2.0 ライセンス (商用利用可能) Raspberry Pi のハードウェア条件から判断すると、最初に試すには E2B レベルの方が適しています。\nステップ 4: API を開始して LAN アクセスを開く\rモデルがロードされた後、まずローカル ポートで API (4000) を開始し、HTTP リクエストを通じてモデル リストが返されることを確認します。\n問題は、デフォルトではこのマシンのみを監視し、LAN 上の他のデバイスは直接アクセスできないことです。\n起動パラメータでホストを直接設定できないため、ポート転送に socat を使用して、Raspberry Pi の外部ポート要求を LM Studio の内部ポートにブリッジし、LAN アクセスを実現しました。\n結果はうまくいきました。同じ LAN 上の MacBook 上のモデルのリストを正常にリクエストして取得することができました。\nステップ 5: エディター (Zed) にアクセスします。\rLM Studio のローカル サービスは OpenAI API フォームと互換性があるため、カスタム base_url をサポートするほとんどのツールに直接アクセスできます。\nRaspberry Pi 上の Gemma 4 インスタンスを指す新しい LLM プロバイダーを Zed に追加したところ、エディターでのチャット テストに合格しました。\n実際の使用感の判断\rこのパッケージは次の用途に適しています。\nローカルオートメーションスクリプト 同時実行性とリアルタイム要件が低い補助タスク 個人学習とエッジデバイスの実験 以下にはあまり適していません:\n高頻度の対話型チャット 応答遅延の影響を受けやすい開発コラボレーション シナリオ 結論は\rGemma 4 (E2B) を Raspberry Pi 5 で実行することは実現可能で、予想よりもうまく機能します。\nオフラインで実行し、ツールを入手し、軽度および中度のタスクを完了できるようにすることが目標である場合、このルートは試してみる価値があります。スムーズなリアルタイム インタラクションが目標の場合でも、より強力なハードウェアを入手することをお勧めします。\n","date":"2026-04-08T18:42:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/08/gemma4-on-raspberry-pi5-benchmark/","title":"Gemma 4 を実行している Raspberry Pi 5 の実際のテスト: 実行可能ですが、応答が遅い"},{"content":"この記事では、OpenClaw をローカル Gemma 4 モデル (Ollama を通じて提供されるインターフェイス) に接続する方法を説明します。\nローカル展開が完了していない場合は、以下を参照してください。\n如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南 ステップ 1: Ollama API サービスを開始する\rまず Ollama サービスを開始します。\n1 ollama serve 次のコマンドを使用して、API が適切に動作しているかどうかを簡単にテストできます。\n1 2 3 4 curl http://localhost:11434/api/generate -d \u0026#39;{ \u0026#34;model\u0026#34;: \u0026#34;gemma4:12b\u0026#34;, \u0026#34;prompt\u0026#34;: \u0026#34;你好\u0026#34; }\u0026#39; モデル出力を返すことができる場合は、ローカル API が使用可能です。\nステップ 2: Ollama に接続するように OpenClaw を構成する\rOpenClaw 構成ファイルのパスは通常次のとおりです。\n1 ~/.openclaw/config.yaml config.yaml を編集し、ローカル モデル エントリを models に追加します。\n1 2 3 4 5 6 7 8 models: # 你已有的模型配置... gemma4-local: provider: ollama base_url: http://localhost:11434 model: gemma4:12b timeout: 120s ステップ 3: デフォルトのモデルを設定する (オプション)\rGemma 4 をデフォルトで使用する場合は、以下を追加できます。\n1 default_model: gemma4-local ステップ 4: OpenClaw を再起動して確認する\rOpenClaw を再起動します。\n1 openclaw restart モデルのリストを表示します。\n1 openclaw models list 会話テストを開始します。\n1 openclaw chat --model gemma4-local \u0026#34;你好\u0026#34; ダイアログが正常に戻った場合、OpenClaw はローカル Gemma 4 に正常に接続されています。\n一般的なトラブルシューティング\rconnection refused: まず、ollama serve が実行されているかどうかを確認します。 モデルが見つかりません: モデル名が ollama list (たとえば、gemma4:12b) と一致しているかどうかを確認します。 応答タイムアウト: timeout は適切に増やすことができ、小さいモデルを最初にテストする必要があります。 ","date":"2026-04-08T18:18:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/08/openclaw-connect-gemma4-local/","title":"OpenClaw とローカル Gemma 4 のドッキング: 完全な構成ガイド"},{"content":"Gemma 4 をラップトップ上でローカルに実行したい場合、現時点では Ollama が最も手間のかからない方法の 1 つです。複雑な環境をいじらなくても、通常は 5 分程度で実行できます。\nステップ 1: Ollama をインストールする\rhttps://ollama.com を開き、対応するシステムのインストール パッケージをダウンロードします。 システムごとにインストールを完了します。 macOS: Applications にドラッグします。 Windows: .exe インストーラーを実行します。 Linux: 公式 Web サイトで提供されているインストール スクリプトを使用します。 インストールすると、Ollama はバックグラウンド サービスとして実行されます。初期インストールを除き、毎日簡単なコマンドのみを使用できます。\nステップ 2: Gemma 4 モデルをダウンロードする\rターミナルを開いて次を実行します。\n1 ollama pull gemma4:4b マシンのパフォーマンスが高い場合は、12b または 27b に変更できます。ダウンロードが完了すると、モデルはローカルに保存されます。\nダウンロードしたモデルを表示します。\n1 ollama list ステップ 3: モデルを起動する\r1 ollama run gemma4:4b これにより、ターミナルで対話型セッションが開きます。質問を入力して Enter キーを押すだけです。セッションを終了するには、次のように入力します。\n1 /bye Web チャット インターフェイスを希望する場合は、Open WebUI とともに使用できます。 Ollama をブラウザ側 UI にラップできます。これは通常、Docker を通じて数分で構成できます。\nラップトップのパフォーマンス最適化に関する提案\rApple Silicon (M2/M3/M4): デフォルトでは金属が使用されており、通常、加速効果は非常に優れています。 12B も良い経験をしています。 NVIDIA グラフィックス カード: 互換性のある GPU が検出されると、CUDA が自動的に使用されます。事前にドライバーをアップデートすることをお勧めします。 CPU のみの推論: 実行できますが、大規模なモデルは大幅に遅くなります。ほとんどの CPU のみのシナリオでは、4B を優先することをお勧めします。 メモリを解放する: 大きなモデルをロードする前に、メモリを消費するアプリケーションを閉じるようにしてください。経験則として、10 億パラメータごとに約 0.5GB 到 1GB のメモリが必要です。 モデルの選び方\rGemma 4 1B: 軽量の Q\u0026amp;A、基本的な要約、および高速なクエリに適しています。複雑な推論能力には限界があります。 Gemma 4 4B: 速度と品質のバランスが取れており、ほとんどの日常タスク (書き込み支援、コード支援、データ要約) に適しています。 Gemma 4 12B: より長いコンテキストとより複雑なタスクに適しており、コーディングと推論のシナリオでより安定しています。 Gemma 4 27B: 需要の高いタスクに適しており、効果はクラウド大規模モデルに近いですが、ハードウェア要件は大幅に高くなります。 ","date":"2026-04-08T18:06:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/08/run-gemma4-on-laptop/","title":"ラップトップで Gemma 4 を実行する方法: 5 分間のローカル導入ガイド"},{"content":"携帯電話で Gemma 4 をオフラインで体験したい場合は、この記事でインストールから実際の機能までを段階的に説明します。\nステップ 1: アプリを入手する\rGoogle AI Edge Gallery は現在 Google Play では利用できないため、APK サイドローディング経由でインストールする必要があります。\nAndroid デバイスで次のように入力します。\n设置 -\u0026gt; 应用 -\u0026gt; 特殊应用权限 -\u0026gt; 安装未知应用\nそれから：\n使用しているブラウザ (Chrome や Firefox など) を見つけて、[このソースからの許可] をオンにします。 モバイル ブラウザで Google AI Edge Gallery の GitHub リリース ページを開きます。 アドレス: https://github.com/google-ai-edge/gallery/releases 最新の .apk インストール パッケージをダウンロードします。 ダウンロードが完了したら、通知バーまたはファイル マネージャーでインストール パッケージをクリックし、プロンプトに従ってインストールを完了します。 ネットワークが正常な場合、この手順は通常、完了するまでに約 2 分かかります。\nステップ 2: 初めて開いて認証する\rAI Edge Gallery を初めて開くと、アプリケーションはモデル ファイルを保存するためのストレージ アクセス許可を要求します。直接許可することをお勧めします。許可しない場合、アプリケーションはモデルをダウンロードまたはロードできません。\n通常、ホームページには次の入り口が表示されます。\nAsk Image: 画像理解タスク (画像の説明、画像に関する質問に答える) AI Chat: 通常のテキスト会話 Summarize: テキストを貼り付けて概要を生成します Smart Reply: 返信候補の生成 ほとんどのユーザーが最もよく使用するのは AI Chat です。\nステップ 3: Gemma 4 モデルをダウンロードする\r「AI Chat」と入力します。 プロンプトに従って「Get Models」をクリックします。 モデルリストで Gemma 4 バージョンを選択します (対応するボリュームが表示されます)。 デバイスの性能に応じてモデルを選択します。電話機が 8GB RAM の場合は、最初に Gemma 4 4B から開始できます。 Download をクリックすると、バックグラウンドでダウンロードが開始されます。 注: モデルが大きいほど、ダウンロード時間は長くなります。複数のモデルをダウンロードし、必要に応じて後で切り替えることもできます。ダウンロードしたモデルはローカルに保存されるため、再度ダウンロードする必要はありません。\nステップ 4: 会話を開始する\rモデルのダウンロードが完了したら、次のようにします。\nモデル名をクリックしてロードします (モデルのサイズとデバイスの機能に応じて、最初のロードには通常 10 ～ 30 秒かかります)。 チャット ボックスに質問を入力して送信してください。 モデルはローカルで応答を生成し、データはクラウドにアップロードされません。 一般に、最初の応答はわずかに遅くなりますが、これはモデルがウォームアップするときの正常な現象です。通常、同じセッション内での後続の応答はより速くなります。\nステップ 5: ビジュアル機能を体験する (Gemma 4 マルチモーダル)\rGemma 4 マルチモーダル バージョンをダウンロードした場合:\nメインメニューに戻り、「Ask Image」と入力します。 写真を選択するか、直接写真を撮ります。 尋ねたい質問を入力します (たとえば、「この写真には何が写っていますか?」または「この写真のどのテキストに注意を払う必要がありますか?」)。 モデルがローカルで分析され、結果が返されるまで待ちます。 この機能はオフラインで動作し、画像コンテンツは外部サーバーに送信されません。\n","date":"2026-04-08T17:55:53+08:00","permalink":"https://www.knightli.com/ja/2026/04/08/android-gemma4-install-run-guide/","title":"Android での Gemma 4 のインストールと実行: 開始するための完全なガイド"},{"content":"メモリを購入したり、チップを探したり、オーバークロックを実行したりするときに、「このメモリにはどのようなチップとバージョン (DIE) が搭載されていますか?」という質問がよくあります。\nこの記事では、Samsung、Micron/Spectek、SK hynix に焦点を当てて、一般的な判断方法を一連の運用プロセスにまとめます。\nサムスン粒子\r命名規則\r2.png 識別内容 (Samsung DDR4 名前付きフィールド):\n1. SAMSUNG Memory: K 2. DRAM: 4 3. DRAM Type: A = DDR4 SDRAM (1.2V VDD) 4. Density: 4G=4Gb, 8G=8Gb, AG=16Gb, BG=32Gb 5. Bit Organization: 04=x4, 08=x8, 16=x16 6. # of Internal Banks: 5 = 16 Banks 7. Interface (VDD, VDDQ): W = POD (1.2V, 1.2V) 8. Revision: M/A/B/C/D/E/F/G = 1st~8th Gen 9. Package Type: B = FBGA (Halogen-free \u0026amp; Lead-free, Flip Chip) M = FBGA (Halogen-free \u0026amp; Lead-free, DDP) 2 = FBGA (Halogen-free \u0026amp; Lead-free, 2H TSV) 3 = FBGA (Halogen-free \u0026amp; Lead-free, 2H 3DS) 4 = FBGA (Halogen-free \u0026amp; Lead-free, 4H TSV) 5 = FBGA (Halogen-free \u0026amp; Lead-free, 4H 3DS) 10. Temp \u0026amp; Power: C = Commercial Temp (0°C ~ 85°C) \u0026amp; Normal Power I = Industrial Temp (-40°C ~ 95°C) \u0026amp; Normal Power 11. Speed: PB = DDR4-2133 (1066MHz @ CL=15, tRCD=15, tRP=15) RC = DDR4-2400 (1200MHz @ CL=17, tRCD=17, tRP=17) TD = DDR4-2666 (1333MHz @ CL=19, tRCD=19, tRP=19) RB = DDR4-2133 (1066MHz @ CL=17, tRCD=15, tRP=15) TC = DDR4-2400 (1200MHz @ CL=19, tRCD=17, tRP=17) WD = DDR4-2666 (1333MHz @ CL=22, tRCD=19, tRP=19) VF = DDR4-2933 (1466MHz @ CL=21, tRCD=21, tRP=21) WE = DDR4-3200 (1600MHz @ CL=22, tRCD=22, tRP=22) YF = DDR4-2933 (1466MHz @ CL=24, tRCD=21, tRP=21) AE = DDR4-3200 (1600MHz @ CL=26, tRCD=22, tRP=22) 例\r最初の行: 「SEC 843」重要な情報は、843 がメモリ粒子の製造日を表します。 2 行目:「K4A4G08」 重要な情報は、4G08 がメモリ粒子の容量とビット幅を表すことです (AG は 16Gb の容量を表します)。 3 行目:「5WT BCTD」の重要な情報は、T、TD、T は詳細なバージョンを表します。 T-DIEです。 TD はメモリの周波数とタイミングを表し、TD は 2666 C19、RC は 2400 C17、PB は 2133 C15 です。 4行目：コーナーマーク不明 経験的に一般的に見られる Samsung DIE には A/B/C/D/E/F/M/S/T などが含まれますが、異なる容量の世代間のカバレッジは完全に一貫しているわけではありません。実際に判断する際には、文字単体だけで判断するのではなく、「完全採点＋対照表」と合わせて確認することをおすすめします。\nミクロン粒子\r1) まずはシルクスクリーンを見てください\r1行目：「7UE75」 日付コード:7U はペレット生産イベントを表します 7は17年を表します U は 42 週を表します (実際には、U は 26 個の英語文字で 21 桁、21*2=42)、 ダイ リビジョン: E はパーティクル バージョンを E-DIE として表します。 拡散国：7は粒子の生産地7（台湾）を表す\nカプセル化の国: 5 は粒子 5 のカプセル化の場所を表します (中国本土)\n2 行目:「D9VPP」Micron の FBGA (コード化された部品番号) より多くの粒子情報を Micron クエリ システムを通じてデコードする必要がある\n2) 公式FBGA情報クエリ\rfbga コードを使用して、次の URL から部品番号をクエリします。\nhttps://www.micron.com/support/tools-and-utilities/fbga 3) 品番命名規則\r例： FBGAコード: D9VPP part number: MT40A1G8SA-075:E\n40 は DDR4 を表し、 A は電圧、 1G8 はパーティクルの容量とビット幅を表します 1G8は8Gb 8ビット、 512M16 は 8Gb 16 ビット、 075は周波数とタイミングを表します 075は2666C19、 083は2400C17、 093Eは2133 C15、 E粒子版E-DIE\nSpectek (Big S) (ミクロン白色フィルムシステム)\r番号：PS029-093 TP コード PS029 は Micron FBGA コードに似ています。公式ウェブサイトでも情報を確認できます。 お問い合わせ先： https://www.spectek.com/menus/mark_code.aspx 元の文書アドレス http://am.adianshi.com:6805/%E5%BC%80%E5%8D%A1%E8%BD%AF%E4%BB%B6/%E6%96%87%E6%A1%A3/spectek_flash.pdf ハイニックス顆粒\r命名規則\r1. SK hynix MEMORY\n2. PRODUCT FAMILY: 5 = DRAM\n3. PRODUCT MODE: A = DDR4 SDRAM\n4. POWER SUPPLY: N = VDD \u0026amp; VDDQ = 1.2V\n5-6. DENSITY \u0026amp; REFRESH: 1G=1Gb, 2G=2Gb, 4G=4Gb, 8G=8Gb, AG=16Gb, BG=32Gb 7. ORGANIZATION: 4=x4, 8=x8, 6=x16\n8. DIE TYPE: N=Non-TSV, T=TSV\n9. DIE GENERATION: M/A/B/C/D/E/F/G = 1st~8th\n10. PACKAGE TYPE: F=FBGA SDP, J=Flipchip SDP, M=FBGA DDP, P=Flipchip Planar DDP, 2=TSV 2 high stack, 4=TSV 4 high stack\n11. PACKAGE MATERIAL: R = Lead Free \u0026amp; Halogen Free (ROHS compliant)\n12-13. SPEED (tCL-tRCD-tRP):\nTF=DDR4-2133 15-15-15, UH=DDR4-2400 17-17-17, UL=DDR4-2400 20-18-18, VK=DDR4-2666 19-19-19, VN=DDR4-2666 22-19-19, WM=DDR4-2933 21-21-21, XN=DDR4-3200 22-22-22 14. OPERATING TEMPERATURE \u0026amp; POWER CONSUMPTION:\nC = Commercial Temp (0°C ~ 85°C) \u0026amp; Normal Power R = Commercial Temp (0°C ~ 85°C) \u0026amp; Reduced IDD6 例\r2 番目の行番号: 「H5AN8G8NCJR」重要な情報 8G8 はパーティクル容量 8Gb、ビット幅 8bit を表し、C はパーティクルのバージョン C-DIE を表します。 3行目の行番号: -「VKC 829A」 重要な情報 VK は周波数とタイミングの略です。 829は製造日を表します。 参考資料と説明書\rこの記事は技術的な知識と購入のレビューを目的としたものであり、購入を約束するものではありません。 異なるバッチでは重大な変更が発生する可能性があり、結論は実際の製品に基づくものとします。 参照元（整理）：https://www.bilibili.com/read/cv2519652/?opus_fallback=1 公式問い合わせ: https://www.micron.com/support/tools-and-utilities/fbga https://www.spectek.com/menus/mark_code.aspx http://am.adianshi.com:6805/%E5%BC%80%E5%8D%A1%E8%BD%AF%E4%BB%B6/%E6%96%87%E6%A1%A3/spectek_flash.pdf ","date":"2026-04-06T17:06:21+08:00","permalink":"https://www.knightli.com/ja/2026/04/06/memory-die-identification-guide/","title":"メモリ粒子識別ガイド: Samsung、Micron、Hynix の番号の見方"},{"content":"VS Code の GitHub Copilot の「コミット メッセージの生成」は非常に便利な機能です。クォータを使い果たした後のリセット期間は非常に長くなります。 この記事は、ローカル エージェント スキルを使用してこの機能を置き換える試みです。\n問題と目標\rこの記事の目的は、直接実装できる代替手段のセットを提供することです。つまり、git-commit-push-zh スキル エージェントを使用して、標準化された送信とプッシュを完了します。\n代替: git-commit-push-zh\rこのスキルは、「現在の変更」を固定プロセスに収束します。\n変更ステータスを表示します。 現在のブランチを確認します。 変更を一時的に保存します。 中国語の提出情報を生成します。 コミットを実行します。 リモートブランチにプッシュします。 対応するコマンドは次のとおりです。\n1 2 3 4 5 git status --short git branch --show-current git add -A git commit -m \u0026#34;\u0026lt;中文提交信息\u0026gt;\u0026#34; git push origin \u0026lt;当前分支\u0026gt; 情報提案仕様書の提出\r推奨される統一形式:\n1 \u0026lt;类型\u0026gt;(\u0026lt;范围\u0026gt;): \u0026lt;中文摘要\u0026gt; タイプの例:\nfeat: 新機能 fix: 問題を修正 docs: ドキュメントの更新 refactor: コードのリファクタリング chore: メンテナンスの変更 例：\nfeat(site): 新增全站 head 广告脚本注入 fix(i18n): 修正 relref 相关文章链接路径 chore(content): 合并 AI 工作流分类到 AI工具 一般的な障害シナリオ\rnothing to commit: 現在、送信する変更はありません。プッシュを停止してください。 push が失敗しました: 最初に権限、リモート ブランチのステータス、競合を確認してください。 SSH/権限の例外: 認証情報と権限を確認して、再試行してください。 付録: オリジナル SKILL.md\r次の内容は git-commit-push-zh の元のドキュメントであり、その後の再利用とメンテナンスを容易にするためにそのまま保持されます。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 --- name: git-commit-push-zh description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。 --- # 中文提交并推送 使用此技能将当前仓库改动一次性提交并推送到远端。 ## 工作流程 1. 查看变更状态：`git status --short`。 2. 确认当前分支：`git branch --show-current`。 3. 暂存当前变更：`git add -A`。 4. 生成中文提交信息（简洁、可检索）。 5. 执行提交：`git commit -m \u0026#34;\u0026lt;中文提交信息\u0026gt;\u0026#34;`。 6. 执行推送：`git push origin \u0026lt;当前分支\u0026gt;`。 ## 提交信息规范（中文） 1. 建议格式：`\u0026lt;类型\u0026gt;(\u0026lt;范围\u0026gt;): \u0026lt;中文摘要\u0026gt;`。 2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。 3. 摘要要求：准确描述本次改动，不写空话。 4. 若仅少量变更，也保持可读性与可检索性。 示例： - `feat(site): 新增全站 head 广告脚本注入` - `fix(i18n): 修正 relref 相关文章链接路径` - `chore(content): 合并 AI 工作流分类到 AI工具` ## 错误处理 1. 若无可提交变更（nothing to commit），明确告知并停止 push。 2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。 3. 常见 SSH/权限问题可在用户确认后重试高权限环境。 ## 输出约定 1. 汇报提交哈希、分支名、提交信息。 2. 汇报 push 结果（成功或失败原因）。 3. 仅在确有失败时提供下一步最小操作建议。 ","date":"2026-04-06T13:09:49+08:00","permalink":"https://www.knightli.com/ja/2026/04/06/replace-vscode-generate-commit-message-after-copilot-quota/","title":"エージェント スキルを使用して、VS Code の Copilot の「コミット メッセージの生成」機能を置き換える"},{"content":"Ollama モデルが実際に GPU 上で実行されているかどうかを確認する最も直接的な方法は、現在ロードされているモデルのプロセッサ使用状況情報を確認することです。\nコマンドを使用する\r1 ollama ps 出力例\r1 2 NAME ID SIZE PROCESSOR UNTIL llama3:70b bcfb190ca3a7 42 GB 100% GPU 4 minutes from now PROCESSOR 列の解釈方法\r100% GPU: モデルは GPU メモリに完全にロードされています。 100% CPU: モデルはシステム メモリに完全にロードされています (GPU 推論は使用されません)。 48%/52% CPU/GPU: モデルは一部がメモリ内にあり、一部がビデオ メモリ内にあり、混合負荷です。 実践的なアドバイス\rGPU を使用する予定なのに 100% CPU が表示される場合は、まずグラフィックス ドライバー、CUDA/ROCm 環境、および Ollama ランタイム パラメーターを確認してください。 モデルパラメータの数が多く、ビデオメモリが不足している場合、通常、CPU/GPU 混合負荷が発生します。 パフォーマンスの問題のトラブルシューティングを行う場合は、最初に ollama ps を実行し、次に速度データを確認してボトルネックをより迅速に特定します。 要約する\rollama ps は、モデルが実際に GPU を使用しているかどうかを判断する最初のステップです。 PROCESSOR 列に注目して、現在の読み込み位置をすばやく確認し、それに応じてその後の最適化の方向を決定します。\n","date":"2026-04-06T10:15:18+08:00","permalink":"https://www.knightli.com/ja/2026/04/06/check-ollama-model-loaded-on-gpu/","title":"Ollama モデルが GPU にロードされているかどうかを確認する方法"},{"content":"Hugo の多言語ブログを維持している場合、頻繁に次のような問題点に遭遇するでしょう。\n中国語を作成した後、英語バージョンと繁体字中国語バージョンを同時に生成する必要があります。 3 つの言語ファイルは一貫した構造を持っている必要があります 前付は翻訳され、Hugo 形式に準拠する必要があります sync-post-translations は、このシナリオ用に設計されたエージェント スキルです。\nこのスキルはどのような問題を解決しますか?\rsync-post-translations のポジショニングは非常に明確です。\nindex.zh-cn.mdをソースファイルとして取得します 同じディレクトリ内で index.en.md、index.zh-tw.md を生成または更新します マークダウン構造の一貫性を保つ 前付に明確なルールを適用する (特に date、slug) 適用可能なトリガーワードの例:\n「英語と繁体字の同時通訳」 「この記事を英語と繁体字中国語に同期します」 スキルのディレクトリ構造\r1 2 3 4 .\\sync-post-translations\\ ├─ SKILL.md └─ agents\\ └─ openai.yaml コアコード 1: SKILL.md\r以下は、このスキルのコア ルール ファイルです。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 --- name: sync-post-translations description: 将 Hugo 文章从简体中文源文件（`index.zh-cn.md`）同步翻译为英文（`index.en.md`）和繁体中文（`index.zh-tw.md`）。当用户提出“en 繁体”“同步翻译英文繁体”或要求同时生成/更新两种语言版本且需保持 front matter 与 Markdown 结构一致时使用。 --- # 同步文章翻译 使用此技能为同一篇文章生成或更新多语言版本。 ## 工作流程 1. 在目标文章目录中定位源文件 `index.zh-cn.md`。 2. 读取完整 front matter 与正文内容。 3. 在同目录创建或更新 `index.en.md` 与 `index.zh-tw.md`。 4. 确保三语结构对齐后执行 Hugo 构建检查。 ## 翻译规则 1. 严格保留 `slug` 原值。 2. `date` 统一规范为 Hugo 常用带时间格式（RFC3339），示例：`2026-04-05T10:00:00+08:00`。 3. 自然翻译以下 front matter 字段：`title`、`description`、`tags`、`categories`。 4. 保持 Markdown 结构不变：标题层级、列表形态、代码块、链接与命令行示例。 5. 技术标识符保持原样：文件名、CLI 参数、模型名、设备名、URL、包名等。 6. 若 YAML 的 `title` 含有 `:`，必须加引号，避免解析报错。 7. 在不改变语义前提下，使用目标语言自然标点与表达习惯（`en`、`zh-tw`）。 ## 输出约定 1. 仅在源文章同目录写入目标文件。 2. 汇报变更的文件路径。 3. 条件允许时执行 `hugo --source . --destination public`，并反馈通过/失败；失败时给出关键报错行。 ## 质量标准 1. 全文术语前后一致。 2. 避免机器直译感，优先可发布文风。 3. 章节内容完整，不省略示例、注意点与总结。 コアコード 2: エージェント/openai.yaml\rこのファイルは、エージェント側のスキルの表示とデフォルトのプロンプト単語を定義します。\n1 2 3 4 interface: display_name: \u0026#34;同步文章翻译\u0026#34; short_description: \u0026#34;生成或更新 EN + ZH-TW 翻译稿\u0026#34; default_prompt: \u0026#34;使用该技能在同一 Hugo 文章目录中，从 `index.zh-cn.md` 生成或同步 `index.en.md` 与 `index.zh-tw.md`，保留 `date` 与 `slug`，保持 Markdown 结构一致，并执行 Hugo 构建校验。\u0026#34; 実際の通話例\r1) 人間指向の自然言語トリガー\r1 2 请把 content/post/2026/04/06/index.zh-cn.md 同步翻译成英文和繁体， 要求 date 用 RFC3339，slug 不变，最后跑 hugo 校验。 2) 期待される出力\r1 2 3 4 5 6 7 已更新： - content/post/2026/04/06/index.en.md - content/post/2026/04/06/index.zh-tw.md 构建校验： - hugo --source . --destination public - 结果：PASS これらのルールが重要な理由\rslug は変更されず、URL と過去の外部リンクを安定させることができます。 date RFC3339 (タイムゾーン付き) を統合して、時間解像度における Hugo/トピックの曖昧さを回避します。 Markdown 構造は変更されないため、翻訳されたディレクトリ、コード ブロック、ショート コードのレンダリングの位置がずれることを回避できます。 技術識別子は翻訳されないため、「コマンドが使用できない/ファイル名が一致しない」問題が大幅に減少します。 よくある落とし穴と回避策\rtitle に : があっても引用符がない場合、YAML は解析に失敗します。 --flag、URL、パッケージ名を変換すると、サンプルコマンドはそのまま無効になります。 3 つの言語のタイトル レベルは一貫性がなく (たとえば、中国語の ## は英語の ### になります)、ディレクトリ アンカーの位置がずれます。 前付を加工せずに本文だけを翻訳すると、ページ一覧やSEO情報が異常になります。 ","date":"2026-04-06T10:00:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/06/agent-skill-sync-post-translations-guide/","title":"AI を使用して Hugo の多言語ブログを維持するエージェント スキル"},{"content":"大規模なモデルをローカルで実行する場合、多くの場合、システム ディスクが最初に爆発しやすくなります。 Ollama は、デフォルトでモデルをユーザー ディレクトリまたはシステム ディレクトリにダウンロードします。事前にパスを計画しておかないと、C ドライブがすぐにいっぱいになってしまいます。\nOllama 共通のデフォルト モデル ディレクトリ\rWindows: C:\\Users\\\u0026lt;用户名\u0026gt;\\.ollama\\models macOS：~/.ollama/models Linux: /usr/share/ollama/.ollama/models (一部インストール方法が異なる場合があります) Windows: モデル ディレクトリをシステム以外のディスクに移行します。\rモデル ディレクトリを D:\\OllamaModels などに移行することをお勧めします。主な方法は、システム環境変数 OLLAMA_MODELS を設定することです。\n1. 新しいターゲットディレクトリを作成します\rたとえば、最初に D:\\OllamaModels を作成します。\n2. システム環境変数を構成する\r変数名: OLLAMA_MODELS 変数値: D:\\OllamaModels これは、「システムのプロパティ -\u0026gt; 詳細設定 -\u0026gt; 環境変数」で追加することも、コマンド ライン (管理者 PowerShell) を使用して設定することもできます。\n1 [System.Environment]::SetEnvironmentVariable(\u0026#34;OLLAMA_MODELS\u0026#34;, \u0026#34;D:\\OllamaModels\u0026#34;, \u0026#34;Machine\u0026#34;) 3. Ollama を再起動します (またはシステムを再起動します)。\r環境変数が有効になったら、Ollama サービス/アプリケーションを再起動します。有効になったかどうかわからない場合は、コンピュータを直接再起動するのが最も安全です。\n4. 新しいディレクトリが有効かどうかを確認します\rモデルをダウンロードまたはプルした後、新しいファイルが D:\\OllamaModels の下に表示されるかどうかを確認します。\n5. 古いディレクトリをクリーンアップします（それが正しいことを確認した後）\r新しいディレクトリでモデルが正常に動作していることを確認してから、古いディレクトリの内容を削除して、C ドライブのスペースを解放します。\nよくある質問\r設定した後もCドライブに書き込まれたままの場合はどうすればよいですか?\rまず、環境変数が「現在のセッションの一時変数」ではなく「システム変数」であることを確認します。 Ollama プロセスが再起動されたことを確認します。 変数名が正しいことを確認してください。それは OLLAMA_MODELS である必要があります。 古いモデルのファイルを移行する必要がありますか?\r再度ダウンロードしたくない場合は、Ollama を停止した後、古いモデルを新しいディレクトリに手動でコピーし、Ollama の検証を開始できます。\n","date":"2026-04-06T09:38:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/06/ollama-model-storage-path-and-migration/","title":"Ollama モデルのデフォルトの保存場所と移行方法 (C ドライブがいっぱいになるのを防ぐため)"},{"content":"Linux 上で Ollama を完全に削除する必要がある場合は、以下の手順に従ってください。この記事では、サービス、実行可能ファイル、モデル ディレクトリ、および ollama ユーザーとユーザー グループをクリーンアップします。\nアンインストール前の注意事項\r次のコマンドは、ネイティブ Ollama モデル ファイル (通常は /usr/share/ollama) を削除します。最初にバックアップする必要があるかどうかを確認してください。 このコマンドはデフォルトで sudo を使用します。現在のアカウントに管理者権限があることを確認してください。 1. systemd サービスを停止して削除します。\r1 2 3 4 sudo systemctl stop ollama sudo systemctl disable ollama sudo rm -f /etc/systemd/system/ollama.service sudo systemctl daemon-reload 2. Ollama 実行可能ファイルを削除します\r1 2 3 4 OLLAMA_BIN=\u0026#34;$(command -v ollama)\u0026#34; if [ -n \u0026#34;$OLLAMA_BIN\u0026#34; ]; then sudo rm -f \u0026#34;$OLLAMA_BIN\u0026#34; fi 3. Ollama 関連のライブラリ ディレクトリを削除します (存在する場合)。\rインストール方法によって Ollama ファイルが lib ディレクトリに書き込まれる場合は、次のようにファイルを消去できます。\n1 2 3 for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do [ -d \u0026#34;$d\u0026#34; ] \u0026amp;\u0026amp; sudo rm -rf \u0026#34;$d\u0026#34; done 4. モデルとデータのディレクトリを削除します。\r1 sudo rm -rf /usr/share/ollama 5. システム ユーザーとグループを削除します (存在する場合)。\r1 2 id -u ollama \u0026gt;/dev/null 2\u0026gt;\u0026amp;1 \u0026amp;\u0026amp; sudo userdel ollama getent group ollama \u0026gt;/dev/null 2\u0026gt;\u0026amp;1 \u0026amp;\u0026amp; sudo groupdel ollama 6. アンインストールが完了したことを確認します\r1 2 command -v ollama || echo \u0026#34;ollama binary not found\u0026#34; systemctl status ollama || true 上記のチェックで ollama が見つからなかった場合は、アンインストールが完了したことを意味します。\n","date":"2026-04-06T09:16:29+08:00","permalink":"https://www.knightli.com/ja/2026/04/06/uninstall-ollama-on-linux/","title":"Linux 上の Ollama を完全にアンインストールします (残留クリーニングを含む)"},{"content":"量子化の中心的な目標は単純です。サイズを小さくし、メモリ使用量を減らし、推論速度を速くする代わりに、精度の損失を小さくすることです。\nローカル展開ユーザーにとって、多くの場合、盲目的に大きなパラメータを追求するよりも、適切な定量的バージョンを選択することの方が重要です。\n定量化とは何ですか\r量子化とは、モデル パラメーターを高精度形式 (FP16 など) からより低いビット幅形式 (Q8、Q4 など) に圧縮することを指します。\nそれは次のように理解できます。\nオリジナルモデル: 高精度の写真のように鮮明ですが、ファイルサイズが大きくなります。 量子化モデル: 圧縮された写真と同様に、細部はわずかに失われますが、軽量かつ高速です。 一般的な定量バージョンの比較\r量化版本 精度/位宽 体积 质量损失 推荐场景 FP16 16 位浮点 最大 几乎无损 研究、评测、追求极致质量 Q8_0 8 位整数 较大 几乎无损 高配电脑，兼顾质量与性能 Q5_K_M 5 位混合 中等 轻微损失 日常主力，平衡方案 Q4_K_M 4 位混合 较小 可接受损失 通用默认，性价比高 Q3_K_M 3 位混合 很小 明显损失 低配设备，能跑优先 Q2_K 2 位混合 最小 较大损失 极限资源场景，临时可用 定量的な命名規則\rgemma-4:4b-q4_k_m を例として取り上げます。\ngemma-4:4b: モデル名とパラメータスケール。 q4: 4 ビット量子化。 k: K-quants (改良された量子化方法)。 m：中（中レベル、s/小、l/大が共通）。 ビデオメモリに基づいてモデルを素早く選択する方法\r内存/显存 推荐量化 4 GB Q3_K_M / Q2_K 8 GB Q4_K_M 16 GB Q5_K_M / Q8_0 32 GB+ FP16 / Q8_0 最初から最大のモデルを追求するのではなく、安定して動作するバージョンから始めて、徐々に精度を向上させることをお勧めします。\n実践的な提案\rデフォルトでは、Q4_K_M から開始され、最初に実際のタスクの効果を確認します。 回答の品質が十分でない場合は、Q5_K_M または Q8_0 にアップグレードしてください。 主なボトルネックがビデオ メモリまたは速度である場合は、Q3_K_M にドロップします。 定量化バージョンに切り替えるたびに、同じバッチのテスト問題を比較に使用してください。 結論は\r品質第一: FP16 または Q8_0。 バランス優先度: Q5_K_M。 共通のデフォルト: Q4_K_M。 ローエンドポケット: Q3_K_M または Q2_K。 モデル選択の本質は、「大きいほど良い」ではなく、「ハードウェア条件下で最も安定して使用可能な効果を実現する」ことです。\n","date":"2026-04-05T22:09:11+08:00","permalink":"https://www.knightli.com/ja/2026/04/05/llm-quantization-guide-fp16-q4-q2/","title":"大規模モデルの定量化の詳細な説明: FP16、Q8、Q5、Q4 ～ Q2 を選択するにはどうすればよいですか?"},{"content":"Gemma 4 は、多模态 と 本地离线运行 に焦点を当てており、軽量エンドから高性能エンドまでの完全なモデル グラデーションを提供します。ほとんどのローカル展開ユーザーにとって重要なのは、「最大のものを選択する」ことではなく、「ハードウェアとタスクに最適なバージョンを選択する」ことです。\nGemma 4 モデルの比較\r次の表は、選択を簡単に参照できるようにしたものです。具体的なパフォーマンスとリソースの使用状況については、実際の展開環境のテストを参照してください。\n模型 参数规模 定位 主要优势 主要限制 推荐场景 Gemma 4 2B 20 亿 超轻量 延迟低、资源占用小、部署门槛最低 复杂推理与长链路任务能力有限 移动端、IoT、轻量问答、简单自动化 Gemma 4 4B 40 亿 轻量增强 比 2B 更稳的理解与生成能力，仍易本地部署 高强度编码/复杂 Agent 任务上限有限 本地助手、基础文档处理、多语言日常任务 Gemma 4 26B 260 亿 高性能（专家混合） 推理和工具调用能力明显提升，适合生产工作流 显存需求显著上升，硬件门槛更高 编程助手、复杂工作流、企业内部 Agent Gemma 4 31B 310 亿 高性能（稠密） 综合能力最强，复杂任务稳定性更好 资源消耗最高，部署与调优成本最大 高要求推理、复杂代码任务、重度自动化 選択方法: ハードウェアとタスクから逆算して考える\r「走れるかどうか、スムーズに走れるかどうか」を主に見る場合は以下から選べます。\n8GB ビデオ メモリ: 優先順位 2B/4B。 12GB ビデオ メモリ: 4B 以降のモデルの量子化バージョンを優先します。 24GB ビデオ メモリ: 26B に焦点を当て、タスクに従って 31B の量子化バージョンを評価できます。 より高いグラフィックス メモリまたは複数のカード: 31B の高精度構成を試すことができます。 安定性と推論速度の確保を優先し、徐々にモデル規模を大きくしていくことをお勧めします。\n4 つの典型的な使用シナリオ\r1) 現地の一般アシスタント\r優先モデル: 4B 理由：コストと効果のバランスが良く、長期の永続運用に適しています。 2) コードと自動化\r優先モデル: 26B 理由: 複数ステップのタスク、ツール呼び出し、およびスクリプト生成においてより安定しています。 3) 難易度の高い推理と複雑なエージェント\r優先モデル: 31B 理由: 複雑なコンテキスト下での安定性が向上し、フォールト トレランスが向上します。 4) エッジデバイスと軽量オフライン\r優先モデル: 2B 理由: リソースに制約のあるデバイスに実装するのが最も簡単です。 導入に関する推奨事項 (Ollama オリエンテーション)\r最も現実的な方法は、「小さなステップで素早く実行する」ことです。\nまず、4B を使用して、実行可能なベースライン (速度、メモリ、エフェクト) を確立します。 実際のタスクの固定テスト セットを作成します (例: 20 の FAQ + 10 の自動タスク)。 次に、26B/31B にアップグレードして、精度、遅延、メモリ コストを比較します。 「メリットが明らかな」場合にのみ、大型モデルをアップグレードしてください。 これにより、最初から大きなパラメータを追求し、遅延、低スループット、複雑なメンテナンスなどの問題が発生することを回避できます。\n結論は\rGemma 4 の真の価値は、単に「より大きなパラメーター」ではなく、軽量から高性能までの実装可能なグラデーションの完全なセットです。\n低コストで迅速にオンラインに接続したい場合は、2B/4B から始めてください。 ローカル AI を本番プロセスに真に統合したい場合は、26B を優先してください。 複雑な推論と高度な自動化に取り組みたい場合は、31B をもう一度試してください。 Gemma 4 に最適な選択は、通常、パラメータが最大のバージョンではなく、ハードウェアの条件とミッションの目標に最もよく一致するバージョンです。\n","date":"2026-04-05T08:30:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/05/google-gemma-4-model-comparison/","title":"Google Gemma 4 モデル比較: 2B/4B/26B/31B 選び方は?"},{"content":"Anthropic の skills/docx は本質的に、「AI が Word ドキュメントをより安定して処理できるようにする」作業仕様書とスクリプト ツールのセットです。\nこれはモデルに単に「.docx を書く」と指示するのではなく、Word 文書の処理をいくつかの明確なパス (新しい文書の作成、コンテンツの読み取り、既存の文書の編集、改訂の処理、コメントの追加、形式の変換、OOXML 構造の検証) に分割します。\n一文だけ読めば次のように理解できます。\nエージェントが .docx をブラック ボックスとして扱うのではなく、ZIP + XML + Office の互換性の問題として扱うようにします。\nこのスキルはどのような問題を解決しますか?\r通常のテキスト生成モデルが Word 文書を処理する場合、いくつかの一般的な問題が発生します。\nテキストを出力するだけであり、実際には構造的に正しい .docx は生成されません。 既存のドキュメントを変更する場合、OOXML 構造は簡単に壊れてしまう コメント、改訂、コメント スレッドに遭遇したとき、どの XML を変更すればよいのかわかりません。 ドキュメントを生成できますが、Word、LibreOffice、Google Docs 間の互換性が不安定です pandoc をいつ使用するか、いつ解凍して XML を直接変更するかがわからない ここに、docx スキルの価値があります。 「何をするか」を事前に制約します。\nコンテンツを読み取るときは、pandoc の使用または解凍を優先してください。 新しく .docx を作成する場合は、docx-js を優先してください。 既存の .docx を編集する場合は、まず「解凍 -\u0026gt; XML の変更 -\u0026gt; 再パッケージ化 -\u0026gt; 検証」に進みます。 モデルをハードコーディングするのではなく、コンパニオン スクリプトを使用して、リビジョン、コメント、スキーマ検証の受け入れの詳細を処理します。 Word 文書の問題は、多くの場合、「テキストが正しく記述されているかどうか」ではなく、「ファイル構造が Office で受け入れられるかどうか」であるため、この考え方は非常に実用的です。\nディレクトリとコードの構成\rこのスキルは大きく4つのレベルに分かれています。\n1. 説明レイヤー: SKILL.md\rSKILL.md はスキル全体への入り口です。主に次の 2 つのことを行います。\nトリガー条件を定義する\nこのスキルは、ユーザーが Word、.docx、コメント、改訂、目次、ページ番号、テンプレート、書式設定されたドキュメントなどを必要とする限り有効にする必要があります。 作業パスを指定する\n毎回即興で作るのではなく、さまざまなタスクに対してどの技術的なルートを取るべきかを明確に書き出します。 内容から判断すると、「使用説明書」と「動作仕様書」の両方です。\n特に価値があるのは、そこにリストされている次のような多くの Word 互換性ルールです。\ndocx-js のデフォルトは US レターではなく A4 です ページが水平の場合、内部ロジックに従って幅と高さのパラメータを渡す必要があります。 リストは手動で挿入できません Unicode 箇条書き 表の幅は表とセルと同時に設定する必要があります。 画像を挿入する場合、typeは省略できません。 生成後、validateを実行 これは、作者が単に「生成できること」ではなく、「安定して開くことができ、安定してレンダリングでき、生成後に互換性があること」を望んでいることを示しています。\n2. Office パッケージ操作層: scripts/office/*\rこの層は、.docx/.pptx/.xlsx を Office Open XML パッケージとして処理する役割を果たします。\nunpack.py\rその機能は、Office ファイルをディレクトリに解凍し、いくつかの補助タスクを実行することです。\nZIPパッケージを解凍します XML/.rels できれいに印刷します .docx に対する merge_runs のオプションの実行 .docx に対する simplify_redlines のオプションの実行 スマート クオートを XML エンティティに変換して、後続の処理リスクを軽減します その設計の焦点は、「単純な解凍」ではなく、エージェントや人間が編集を続けるのに適した状態にファイルを整理することにあります。\npack.py\rこの機能は、変更されたディレクトリを .docx/.pptx/.xlsx に再パッケージ化することです。\n梱包する前に行うべき重要なことが 2 つあります。\nオプションの動作検証と自動修復 XML を再圧縮し、無意味な空白やコメントを削除します。 --original が指定されている場合は、バリデーターと比較されます。これは非常に重要です。\nWord の変更の多くは「元に戻すことができれば成功する」わけではなく、文書の構造とリビジョンの追跡セマンティクスがまだ有効であることを確認する必要があるためです。\nvalidate.py\rこれはスキル全体の品質ゲートです。\n検証をサポートします。\nXML は整形式ですか? 名前空間は正しいですか? すべての種類の ID は一意ですか? 関係性/コンテンツタイプは一致していますか? XSDスキーマに準拠 空白の保持ルールは正しいですか? 挿入、削除、コメントマークは合法ですか? .docx の場合、このステップはほぼコア コンピテンシーです。\n「XML が少しだけ変更されているだけ」のように見える多くの文書の場合、本当の問題はここにあります。\nsoffice.py\rこれは非常にエンジニアリング的なガジェットです。\n単に LibreOffice を呼び出すのではなく、制限された環境向けの互換性処理を準備し、自動的に SAL_USE_VCLPLUGIN=svp を設定し、制限された AF_UNIX ソケットの問題を解決するために必要に応じて shim を構築します。\nこれは、スキルの対象環境が「ローカルデスクトップの手動操作」だけではなく、エージェントやCI、サンドボックスなどの自動化された環境も考慮していることがわかります。\n3. Wordの特殊能力レベル：コメント、修正、朱書き\rcomment.py\rこのスクリプトは、DOCX にコメントを追加する役割を果たします。\nWord のコメントは単一のファイル メカニズムではなく、連携して動作する一連のコンポーネントであるため、その動作は「コメント XML を書く」よりもはるかに複雑です。\nword/comments.xml commentsExtended.xml commentsIds.xml commentsExtensible.xml document.xml のコメント範囲マーカー [Content_Types].xml および document.xml.rels での関係宣言 スクリプトでは、これらの依存関係がすでに考慮されています。\n初めてコメントを追加する場合、テンプレート ファイル、リレーションシップ、コンテンツ タイプが自動的に完成するため、OOXML を手動で変更する際のエラー率を大幅に減らすことができます。\naccept_changes.py\rこのスクリプトの目標は非常に明確です。すべてのリビジョンを受け入れることです。\n実装方法はXMLを自分で修正するのではなく、LibreOfficeのヘッドレス+Basicマクロで.uno:AcceptAllTrackedChangesを調整する方法です。\nWord セマンティクスにおける「リビジョンの受け入れ」は、\u0026lt;w:ins\u0026gt; / \u0026lt;w:del\u0026gt; を削除するほど単純ではないため、この選択は非常に安全です。 XML を直接変更すると、重大な問題が残る可能性があります。\n通常、これを Office エンジン自体で行うと、互換性が向上します。\nvalidators/redlining.py\rこれがこのスキルの最も注目すべき部分です。\n元の文書と変更された文書から「作成者の改訂」を分離し、テキストが一貫しているかどうかを比較して、改訂が追跡された変更構造に正しくラップされているかどうかを判断します。\n言い換えれば、XML 形式をチェックするだけではなく、「リビジョン セマンティクスに従ってドキュメントを編集したか?」をチェックします。\nAI は次のような間違いを犯しやすいため、これはエージェントにとって特に重要です。\nテキストを直接修正します。ただし、\u0026lt;w:ins\u0026gt; / \u0026lt;w:del\u0026gt; は含めません。 他の人の挿入または削除構造の階層を変更する 最終的なテキストは変更されましたが、朱書きのロジックは保持されません このバリデータは、この「表面の可用性とセマンティック エラー」の問題を防ぐためのものです。\n4. スキーマと補助層: schemas/、helpers/、templates/\rschemas/\rここに、OOXML / ECMA / Microsoft 拡張機能関連の XSD の完全なセットを示します。\nこれは、スキルの検証が頭でルールを記述することではなく、可能な限り形式的なスキーマ制約に基づいて行われることを意味します。\nhelpers/\r主なものは次のとおりです。\nmerge_runs.py simplify_redlines.py その機能は、解凍された Word XML を適度にクリーンアップして、構造をより安定させ、編集と比較を容易にすることです。\ntemplates/\rコメント関数が依存する次のような XML テンプレートがここに保存されます。\ncomments.xml commentsExtended.xml commentsIds.xml commentsExtensible.xml people.xml このタイプのテンプレート ファイルは重要です。多くの Word パーツは「不足している場合に自動的に埋められる」わけではなく、Office で受け入れられる形式で事前に設定されている必要があるからです。\n一般的な使用法\rSKILL.md による提案から判断すると、このスキルは次のワークフローに最適です。\nシナリオ 1: 既存の DOCX の読み取りまたは分析\rコンテンツを抽出し、構造を読み取り、Markdown に変換することが目的の場合は、以下を使用します。\n1 pandoc --track-changes=all document.docx -o output.md 基礎となる XML を表示したい場合は、以下を使用します。\n1 python scripts/office/unpack.py document.docx unpacked/ 前者は内容を読むのに適しており、後者は構造を見るのに適しています。\nシナリオ 2: 新しい DOCX を作成する\rスキルの提案は、OOXML を手動でロールするのではなく、docx-js を使用して以下を生成することです。\n1 npm install -g docx 次に、ドキュメントを生成して検証します。\n1 python scripts/office/validate.py doc.docx このルートは次のような場合に適しています。\n報告 memo letter タイトル、目次、フッター、ページネーション、表を含む正式な文書 シナリオ 3: 既存の DOCX を編集する\rこれはスキル全体の中核となるワークフローです。\n1 2 3 python scripts/office/unpack.py document.docx unpacked/ # 修改 unpacked/ 下的 XML python scripts/office/pack.py unpacked/ output.docx --original document.docx ここで重要なのは「XML の変更」ではなく、最後のステップ --original です。\nこれにより、システムはパッケージを返すときに、やみくもにパッケージ化するのではなく、スキーマとレッドライン レベルの検証を実行できるようになります。\nシナリオ 4: すべてのリビジョンを受け入れる\r1 python scripts/accept_changes.py input.docx output.docx このステップは LibreOffice に依存します。\nレビューされた文書を「クリーンなバージョン」に整理するのに適しています。\nシナリオ 5: コメントを追加する\r1 2 python comment.py unpacked/ 0 \u0026#34;Comment text\u0026#34; python comment.py unpacked/ 1 \u0026#34;Reply text\u0026#34; --parent 0 ここでは特別な注意を払う必要があります。スクリプトはコメントの内容と必要なコメント コンポーネントのみを追加します。実際、コメントを対応するテキスト範囲に実際に添付するには、コメントの指示に従ってコメント範囲マーカーを document.xml に追加する必要があります。\nこのスキルの最も注意すべき落とし穴\rSKILL.md をざっと見ただけでは、その「互換性ルール」の価値を過小評価するのは簡単です。\n特に以下の点は覚えておいてください。\n1. .docx はテキスト ファイルではなく、Office パッケージです\r最も危険な誤解は、これを「フォーマットされたテキスト ファイル」として扱うことです。\n実際、変更には以下も含まれる場合があります。\nテキスト XML relationships content types comments / people / ids スキーマ制約 リビジョンセマンティクス そのため、このスキルでは「パッケージの開梱、編集、確認、返却」に重点が置かれています。\n2. docx-js はドキュメントを生成できますが、デフォルトのパラメーターが目的を満たしているという保証はありません。\rSKILL.md は、次のような多くのデフォルト値の落とし穴を強調表示します。\nデフォルトの用紙はA4です 水平方向のページ幅と高さの処理には内部ロジックがあります リストに箇条書き文字を直接挿入することはできません テーブル幅を二重に宣言する必要があります Google ドキュメントはパーセント幅との互換性が低い これは、生成ツールが出発点にすぎず、最終的な品質を保証するものではないことを示しています。\n3. コメントと修正は単一点の修正ではありません\rコメントであっても、変更の追跡であっても、XML を変更するだけの問題ではありません。\n複数のコンポーネント間で一貫性を維持する必要があるため、スキルはこれらのアクションをスクリプト化します。\n4.「オープンできる」は「修正される」という意味ではない\r文書を Word で開くことができるからといって、その構造が正しいとは限りません。\n多くのエラーは、次のシナリオでのみ公開されます。\n再度編集するとクラッシュする レビューモード例外 注釈がありません Google ドキュメントを開いた後にレイアウトが崩れる リビジョンを再度受け入れるときにエラーが発生する したがって、validate.py と pack.py --original は非常に重要です。\n5. 外部ツールを利用する場合は事前に環境を準備する\rこのスキルは、いくつかの種類の外部ツールに依存しています。\npandoc LibreOffice / soffice docx-js Python の依存関係 (defusedxml、lxml など) これらのツールが環境にない場合、エージェントがプロセスを知っていても、それを完全に実行することはできません。\nこのスキルは何に向いていて、何が不向きなのでしょうか？\r適切な\rWord レポートをバッチ生成する 構造化された正式文書の生成 自動変更 .docx 追跡された変更を保存または処理する コメントを自動的に追加する Word ドキュメントをスクリプトまたはエージェント ワークフローに組み込む あまり適していない\rPDF をエクスポートするだけの簡単なシナリオ プレーン テキスト コンテンツのみが必要で、Word 形式は気にしません 手動によるビジュアル編集に完全に依存している 依存関係や環境の準備を一切せずに、すべての Word 自動化を完了したいと考えています。 要約する\rAnthropic の skills/docx の強みは、「Word を生成する」ことではなく、「Word が問題を起こしやすい理由を知り、問題を事前に分解する」ことにあります。\nこれは、ドキュメント生成、基礎となる XML 編集、リビジョン セマンティクス、スキーマ検証、および Office 互換性に関する元々散在していた知識を実行可能なワークフローに編成します。\n単純なドキュメントを時々エクスポートするだけの場合は、少し重く感じるかもしれません。\nただし、シナリオに既存の .docx の変更、コメント、リビジョン、自動バッチ処理、または互換性要件が含まれる限り、この一連のスキルは貴重です。AI が無視する可能性が最も高く、Office ドキュメントが覆される可能性が最も高い詳細を正確に埋めるためです。\n簡単な要約は次のとおりです。\nSKILL.md はエージェントにどちらの方向を取るかを伝える責任があります scripts/office/* は開梱、返品、チェック、Office の互換性を担当します。 comment.py と accept_changes.py は Word の特殊能力を担当します schemas/ とバリデーターは、「機能しているようだ」を「構造的に信頼できる」に改善する責任があります。 コードアドレス：https://github.com/anthropics/skills/tree/main/skills/docx\n","date":"2026-04-04T11:00:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/04/analyze-docx-agent-skill/","title":"Anthropic のエージェント スキル docx の機能、コード構成、使用法、注意事項を分析する"},{"content":"Feiniu NAS には主に 2 つのリモート アクセス方法があります。\nパブリックIP直接接続 FN Connectリモートアクセスサービス 以下は「使い方＋注意事項＋適用シナリオ」に沿って直接参照できるものをまとめたものです。\n方法 1: パブリック IP 直接接続\rこれは、ホーム ネットワークにパブリック IP があり、ルーターでポート転送を構成する必要があるシナリオに適しています。 次に、ブラウザまたは Feiniu アプリにパブリック IPv4/IPv6 アドレスとポート番号を入力してアクセスします。 さらに DDNS を使用し、ドメイン名を通じてアクセスすることもできます。\n注意事項\rFeiniu プライベート クラウド fnOS のデフォルト ポート: HTTP = 8000，HTTPS = 8001 ポート転送が設定されている場合、アクセス アドレスにはポート番号が含まれている必要があります。そうでないと、Feiniu NAS に正しくアクセスできません。 パブリック IP 直接接続には通常、追加のリレーがなく、速度損失が軽減されます。 セキュリティ証明書が正しく構成されていない場合、HTTP はプレーン テキストで送信されます。信頼できるネットワーク環境でのみご使用ください。 多くのブロードバンド ネットワークでは、80、8080 などの一般的なポートがブロックされます。一般的なポートを接続できない場合は、人気のないポートを試してください。 方法2：FN Connectリモートアクセスサービス\rFN Connect は、Feiniu が提供するリモート アクセス サービスです。\n使用後は、Feiniu NAS を識別し、対応する方法でリモート アクセスを有効にするために使用される一意の FN ID を取得します。\n注意事項\rFN Connectを使用するには、Feiniuアカウントに登録またはログインする必要があります。 FN Connect は、HTTPS 経由で安全にアクセスできる、FN ID に対応するサブドメイン名の SSL 証明書を提供します。 FN Connectは、現在のネットワーク環境に基づいて、より適切な接続方法を自動的に選択します。 パブリック ネットワーク直接接続が利用可能な場合、Web ページはパブリック ネットワーク IP 直接接続を使用するかどうかを選択できます。 FN Connect のリレー転送にはトラフィック コストが発生するため、レート制限ポリシーが存在します。 2 つの方法の比較\r维度 公网 IP 直连 FN Connect 上手难度 需要公网 IP + 路由器端口转发 登录账号后按引导配置，门槛更低 访问速度 通常更快、链路更直接 直连时接近直连；中继时可能限速 安全性 取决于你自己的证书与暴露策略 默认支持证书，HTTPS 访问更省心，依赖于飞牛本身的安全 维护成本 需要自行维护网络与安全配置 日常维护成本较低 适合人群 有网络配置经验、追求性能 追求易用与稳定的普通用户 提案を選択する\rネットワーク構成に精通していて、より高い帯域幅とより低い遅延が必要な場合は、パブリック IP 直接接続を優先してください。 使いやすさと安全なアクセス体験を重視する場合は、FN Connect を優先してください。 実際の使用では、FN Connect がデフォルトであり、条件が許せばパブリック IP 直接接続に切り替えるなど、混合することができます。 ","date":"2026-04-04T11:00:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/04/fnos-remote-access-public-ip-vs-fn-connect/","title":"Feiniu NAS にリモートアクセスする 2 つの方法と比較"},{"content":"各デバイスには固有のトップ マークがあり、サプライヤー、デバイス名、材料番号、製造日コード、バッチ番号、ピン 1 の方向を識別するために使用されます。\n写真は上部のシルクスクリーンです。\n部品番号の形式\r部品番号には、ベンダー、製品カテゴリ、部品番号、パッケージ タイプ、材料タイプ、製品グレード (動作温度)、マスク ROM バージョン、およびデバイス リビジョンの情報が含まれます。\nその形式を図 5 に示します。\nSection I: a-c、ブランド、製品カテゴリ、デバイス番号 (つまり、デバイス マスター ID) を識別するために使用されます。 Section II: d-h、パッケージ、材料グレード、内部ボンディング、マスク ROM バージョン、チップ バージョン (つまり、仕様とバージョン情報) を識別するために使用されます。 字段 长度 含义 代码 说明 a (JM) 2 位 品牌名 JM 供应商为 JMicron b (B) 1 位 产品类别 B B = Bridge，S = SOC c (585) 3 位 器件编号 585 与品牌名和产品类别组合形成器件名 JMB585 的序列号 d (Q) 1 位 封装类型 B, L, Q, T B = BGA，L = LQFP，Q = QFN，T = TQFP e (H) 1 位 材料与等级 G, H, I, J G：金线、RoHS、无卤、Ta: 0 至 70°C； H：铜线、RoHS、无卤、Ta: 0 至 70°C I：金线、RoHS、无卤、Ta: -40 至 85°C； J：铜线、RoHS、无卤、Ta: -40 至 85°C f (B) 1 位 内部键合类型 A, B, C, \u0026hellip; 内部键合类型代码 g (A0) 2 位 Mask ROM 版本 A0, A1, A2, \u0026hellip;；\nB0, B1, B2, \u0026hellip;；\nZ0 A* 表示 A 系列版本；B* 表示 B 系列版本；Z0 表示无 Mask ROM h (A) 1 位 芯片版本 A, B, C, \u0026hellip; IC 版本号 ","date":"2026-04-04T10:00:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/04/jmicron-chip-top-mark-part-number-format/","title":"JMicron チップ上部のシルク スクリーン印刷と材料番号コーディングの指示"},{"content":"この記事では、箱から出してすぐにデバッグとフラッシュを開始できるようにすることを目的として、CH347 を使用するときに最も頻繁に使用する一連のリソースをコンパイルします。\nCH347 を初めて使用する場合は、次の順序で環境を準備することをお勧めします。\nまずは公式商品ページをご覧いただき、記載内容をご確認ください 目的に応じて対応するドライバーをインストールしてください SPI Flash フラッシュ ツールを準備し、接続検証を実行する 正式な入り口\rCH347商品ページ：https://www.wch.cn/products/CH347.html 不明なソースや古いバージョンからドライバー パッケージを入手することを避けるために、最初に公式ページからダウンロード エリアにアクセスすることをお勧めします。\nよく使用されるドライバー\r1) CH341PAR.EXE\r使用：\nUSB to JTAG / SPI / I2C / パラレル ポート / GPIO およびその他のインターフェイス ドライバー 該当するシナリオ:\nマルチプロトコル通信や低レベルインターフェースのデバッグにCH347を使用する必要がある場合 2) CH343SER.EXE\r使用：\nUSB から高速シリアル ポートへの Windows 製造元のドライバー 該当するシナリオ:\n主に CH347 をシリアル ポート ツールとして使用し、より高いシリアル ポート レートを必要とします。 SPIフラッシュフラッシュツール\rAsProgrammer：https://github.com/nofeletru/UsbAsp-flash 一般的な用途:\nSPI NOR フラッシュの識別 チップIDの読み取り 元のファームウェアをバックアップする ファームウェアの消去/書き込み/ベリファイ 推奨される操作順序 (落とし穴を避けるため)\rドライバーのインストール後、デバイスを抜き差しし、デバイスマネージャーを開いて正常に認識されるか確認してください。 初めてフラッシュする前に、「読み取り + バックアップ」を実行して元のコンテンツを保持します。 書き込み後は必ずご確認ください。 「書き込みが成功しました」というプロンプトだけを見てはいけません。 チップが認識できない場合は、電源、レベル、配線を確認し、その後ソフトウェア構成を確認してください。 ","date":"2026-04-03T10:00:00+08:00","permalink":"https://www.knightli.com/ja/2026/04/03/ch347-resources-drivers-tools/","title":"CH347 開発用の共通リソースのコレクション: ドライバー、ツール、SPI フラッシュ フラッシュ"},{"content":"マルチオーディオ トラックおよびマルチ字幕ビデオ処理では、-map は FFmpeg の最も重要で最も誤用されやすいパラメータの 1 つです。\n-map を明示的に指定しない場合、FFmpeg はデフォルトのルールに従ってストリームを自動的に選択するため、多くの場合、期待した結果が得られません。例えば：\nエクスポートすると字幕が失われる 間違ったオーディオトラック言語が選択されました 不要なデータストリームが混入している この記事では、最も一般的なシナリオを使用して、-map の使用方法を説明します。\nまずは「流れ」とは何かを理解する\r通常、コンテナー ファイルには複数のコンテンツ ストリーム (ストリーム) が存在します (mp4、mkv など)。一般的なものには次のようなものがあります。\nビデオストリーミング (v) オーディオ ストリーム (a) 字幕ストリーム (s) 添付ファイル/データ ストリーム (フォント、表紙、章など) まず ffprobe を使用して、ファイル内にどのようなストリームがあるかを確認できます。\n1 ffprobe -hide_banner input.mkv -map の基本構文\r最も一般的な書き方は次のとおりです。\n1 -map input_index[:stream_type][:stream_index] 例えば：\n0:v: 1 番目の入力ファイルのすべてのビデオ ストリーム 0:a:0: 入力ファイル 1 のオーディオ ストリーム 1 1:s:1: 2 番目の入力ファイルの 2 番目の字幕ストリーム 例証します:\ninput_index は 0 から始まり、-i のシーケンスに対応します。 stream_index も 0 で始まります 実践例\r1) ビデオは A から、音声は B から来ます\r1 2 3 4 ffmpeg -i english.mp4 -i french.mp3 \\ -map 0:v:0 -map 1:a:0 \\ -c:v copy -c:a aac \\ french.mp4 意味：\nenglish.mp4 の最初のビデオ ストリームを取得します french.mp3 の最初のオーディオ ストリームを取得します 結合された出力は french.mp4 です。 2) 最初の入力のすべてのストリームを保持し、追加のオーディオ トラックを追加します。\r1 2 3 4 ffmpeg -i english.mp4 -i french.mp3 \\ -map 0 -map 1:a:0 \\ -c copy \\ english-french.mp4 意味：\n-map 0 まず、すべてのストリームを最初の入力ファイルに取り込みます 2 番目の入力の最初のオーディオ ストリームを追加します 非常に実践的な 2 つの高度なテクニック\r1) ネガティブ マッピング: 不要なフローを除外します。\rたとえば、最初の入力のすべてのストリームを保持しますが、2 番目のオーディオ ストリームを削除します。\n1 ffmpeg -i input.mkv -map 0 -map -0:a:1 -c copy output.mkv 2) オプションのマッピング: ストリームは存在せず、中断されません。\r一部のファイルには字幕がない場合があります。その場合は、? を使用できます。\n1 ffmpeg -i input.mp4 -map 0:v -map 0:a -map 0:s? -c copy output.mp4 0:s? は、「字幕がある場合はマップし、字幕がない場合はスキップし、エラーは報告されない」ことを意味します。\n一般的なピットの位置\r-map を使用すると、FFmpeg はデフォルトでストリームを自動的に選択しなくなるため、必要なものをすべて書き出す必要があります。 -c copy は、トランスコーディングを行わずにカプセル化とコピーのみを行います。ターゲット コンテナが特定のエンコーディングをサポートしていない場合でも、失敗します。 複数の入力を入力するときに最もよくある間違いは、シリアル番号を入力することです。シリアル番号は -i の順序にのみ依存することに注意してください。 安定したスクリプトを作成したい場合は、まず ffprobe を作成し、次に手書きよりも安定した -map を生成します。 要約する\r-map の中核は 1 つの文です。「どの入力から、どのタイプのストリームを取得し、どのストリームを取得するか」を FFmpeg に明確に指示します。\nマスタリング後は、複数のオーディオトラック、複数の字幕、ファイル間の結合などの複雑なシーンを安定して処理できるようになり、「エクスポート結果が間違っているが原因がわからない」という問題を回避できます。\n","date":"2026-04-02T23:14:03+08:00","permalink":"https://www.knightli.com/ja/2026/04/02/ffmpeg-map-parameter-guide/","title":"FFmpeg の `-map` パラメータの詳細な説明: ビデオ、オーディオ、および字幕ストリームの正確な選択"},{"content":"Let\u0026rsquo;s Encrypt 証明書の有効期限は 90 日間のみです。オンライン サイトでは、証明書の有効期限切れによる HTTPS エラーを回避するために自動更新を構成する必要があります。\ncrontabを手動で追加する(推奨例)\r更新タスクを自分で明示的に管理したい場合は、root ユーザーとして追加します。\n1 sudo crontab -e 次の行を追加します (毎日午前 3 時に 1 回実行)。\n1 0 3 * * * certbot renew --pre-hook \u0026#34;systemctl stop nginx\u0026#34; --post-hook \u0026#34;systemctl start nginx\u0026#34; \u0026gt;\u0026gt; /tmp/certbot-renew.log 2\u0026gt;\u0026amp;1 このコマンドの意味は次のとおりです。\n0 3 * * *: 毎日 03:00 に実行 certbot renew: 有効期限が近づいている証明書を確認して更新します (実際には毎日更新されるわけではありません)。 --pre-hook: 80/443 ポートの競合を避けるために、更新前に Nginx を停止します (スタンドアロン モードで一般的) --post-hook: 更新後のNginxの起動 \u0026gt;\u0026gt; /tmp/certbot-renew.log 2\u0026gt;\u0026amp;1: トラブルシューティングを容易にするためにログをファイルに追加します 最初に更新のシミュレーションを行うことをお勧めします\rスケジュールされたタスクを追加した後、まずプロセスが利用可能かどうかを手動で確認します。\n1 sudo certbot renew --pre-hook \u0026#34;systemctl stop nginx\u0026#34; --post-hook \u0026#34;systemctl start nginx\u0026#34; --dry-run シミュレーションが正常に更新されたことを確認した後、長期実行のためにスケジュールされたタスクに渡されます。\n共通の注意点\rwebroot または nginx プラグインを使用している場合、多くのシナリオで Nginx を停止する必要はありません。代わりに、更新後に構成をリロードすることもできます。 1 certbot renew --deploy-hook \u0026#34;systemctl reload nginx\u0026#34; certbot renew は、証明書の有効期限が近づいた場合にのみ実際の更新を実行するため、1 日に 1 回実行するのが通常の一般的な方法です。\n長期的な運用とメンテナンスを容易にするために、ログ ディレクトリを長期的に追跡可能な場所 (/var/log/letsencrypt/ など) に変更することをお勧めします。\n","date":"2026-04-02T00:00:00Z","permalink":"https://www.knightli.com/ja/2026/04/02/certbot-auto-renew-nginx/","title":"Ubuntu で Let's Encrypt 証明書を自動的に更新する (Certbot + Nginx)"},{"content":"VS Code が突然フリーズしたり、ファンが激しく回転したり、CPU が長時間占有されたりした場合、最も一般的な原因は通常、エディタ自体ではなく、拡張プラグインの競合またはプラグインの異常な動作です。\nこの記事では、問題を特定するために最も時間を節約できる方法を優先して、すぐに実行できる一連のトラブルシューティング パスを示します。\n最初に最速の位置決めを実行します: Extension Bisect を開始します\rStart Extension Bisect の核となるアイデアは次の二項対立です。 各ラウンドでは、拡張機能の半分が一時的に無効になり、再起動されます。 「問題がまだ存在するかどうか」というフィードバックを通じて、疑わしいプラグインが見つかるまで範囲がすぐに狭められます。\n操作手順:\nCtrl+Shift+P (macOS では Cmd+Shift+P) を押してコマンド パネルを開きます。 Start Extension Bisect を入力して実行します。 再起動するたびに、CPU 使用率とフリーズが再発するかどうかを観察します。 数回繰り返すと、VS Code によって疑わしい拡張機能のリストが表示されます。 位置決め後に何をするか\r疑わしいプラグインを見つけたら、次の順序で対処することをお勧めします。\nまずプラグインを最新バージョンに更新してください。 改善が見られない場合は、プラグインを一時的に無効にして 1 ～ 2 日間観察してください。 置き換え可能な機能を持つプラグインについては、より軽量なソリューションへの置き換えが優先されます。 このプラグインを使用する必要がある場合は、その詳細設定を確認し、不要なリアルタイム分析、インデックス作成、または監視機能をオフにしてください。 見落とされがちな2つの「増幅器」\r主な原因がプラグインである場合でも、次の構成により CPU の問題が増幅されます。\n検索範囲が大きすぎます\nたとえば、ビルド製品、依存関係ディレクトリ、ログ ディレクトリをグローバル検索に含めると、引き続きプラグインとファイル インデックスに高い負荷がかかります。\nファイル監視には大きなディレクトリまたはソフト リンクが含まれています\nソフト リンク、キャッシュ ディレクトリ、および自動生成されたディレクトリは、簡単に多数のファイル イベントをトリガーし、拡張機能が繰り返し動作する可能性があります。\nディレクトリは、settings.json で適切に除外できます。たとえば、次のようになります。\n1 2 3 4 5 6 7 8 9 10 11 12 { \u0026#34;search.exclude\u0026#34;: { \u0026#34;**/node_modules\u0026#34;: true, \u0026#34;**/dist\u0026#34;: true, \u0026#34;**/build\u0026#34;: true }, \u0026#34;files.watcherExclude\u0026#34;: { \u0026#34;**/.git/objects/**\u0026#34;: true, \u0026#34;**/node_modules/**\u0026#34;: true, \u0026#34;**/dist/**\u0026#34;: true } } 提案をレビューする\r問題のあるプラグインを見つけた場合は、プラグイン名、トリガーとなるシナリオ、最終的な処理方法の 3 つの情報を記録することをお勧めします。\nこのようにして、次回環境を移行するかシステムを再インストールするときに、同様の問題をすぐに回避できます。\n要約する\rVS Code の高い CPU 使用率をトラブルシューティングするには、最初に Start Extension Bisect を使用して迅速に特定し、次に検索範囲とファイル監視範囲を組み合わせて収束させるのが最も効果的です。\n最初に配置を決めてから最適化する方が、「多数のプラグインをやみくもに無効にする」よりも時間を節約でき、安定性も高くなります。\n","date":"2026-04-01T00:00:00Z","permalink":"https://www.knightli.com/ja/2026/04/01/vscode-extension-cpu-troubleshooting/","title":"プラグインによって引き起こされる VS Code の高い CPU 使用率をトラブルシューティングする方法"},{"content":"家庭用プリンターで最もよくある落とし穴は、パラメーターが十分に高くないことではなく、自分の使用習慣に適していないモデルを購入したことです。\nこの記事では、難しい用語については説明せず、エクスペリエンスに最も影響を与える 4 つの選択ポイントのみに焦点を当て、予算内で長期的に使いやすいマシンを選択するのに役立ちます。\nレーザーまたはインクジェット\rまず実際的な結論を思い出してください。\n白黒文書中心、安定した印刷量、レーザー優先 カラーグラフィック、写真、手作業の資料が必要な場合はインクジェットが優先されます。 インクジェットプリンターの最大の問題は、長期間使用しないとノズルが目詰まりしやすいことです。利点は、写真を印刷できることと、通常、カラー グラフィックスとテキストのパフォーマンスが優れていることです。\nレーザー プリンタの利点は、高速、クリアなテキスト、長期メンテナンスの容易さです。欠点は、カラー モデルと消耗品のコストが通常より高いことです。\n自宅での主なニーズが「白黒の仕事 + 書類」である場合は、通常、白黒レーザー一体型マシンの方が信頼性が高くなります。\nワイヤレス Wi-Fi、ネットワーク ケーブル、それとも USB?\r毎日の使用がスムーズかどうかは、接続方法によって決まります。\nUSB: コンピュータへの固定接続に適しており、最も直接的で安定しています。マルチデバイス共有には追加の設定が必要です Wi-Fi: 携帯電話、タブレット、ラップトップでプレイでき、家庭での使用に最も便利です 网线（以太网）：安定した接続を追求し、自宅や小規模スタジオでの複数人での共有に適しています。 現在、家庭には通常複数のデバイスがあり、携帯電話やタブレットでの印刷ニーズがますます一般的になっています。\n面倒な設定をしたくない場合は、Wi-Fi対応機種を優先してください。\nネットワーク ケーブルをルーターに接続すると、家庭内の複数のデバイスに安定した印刷を提供することもできます。 USB を共有することもできます (たとえば、プリント サーバーや OpenWrt 経由で) が、構成はより複雑になります。\n自動両面か片面か？\r自動両面印刷は見落とされがちですが、非常に便利な機能です。\n長い文書を印刷する際に用紙を節約し、手動で裏返す手間を省く自動両面モデルもあります。配布資料、契約書、学習資料を頻繁に印刷する家庭にとって、この機能は価値があります。\n1 ～ 3 ページをたまにしか印刷しない場合は、片面モデルで十分ですが、長期的には自動両面の方が優れています。\nカートンの選択\rカートンの構成は、毎日の使いやすさに直接影響します。次の 2 つの点に焦点を当てることをお勧めします。\n密閉カートンの場合、防塵・防湿性が向上し、長期メンテナンスが容易になります。 用紙入力容量: 小さな紙箱には通常約 100 ～ 200 ページが入ります。大きな紙箱には 500 ページが入ることが多く、紙パック全体を直接箱に入れることができるため、大量に印刷する家庭に適しています。 学習資料や仕事の書類を頻繁に印刷する場合は、大容量の紙箱を優先すると、用紙を追加する頻度が大幅に軽減されます。\n要約する\r家庭用プリンターの場合、「パラメーターが高ければ高いほど良い」ではなく、「使用シーンに適したものが良い」のです。\nまず文書を優先するかカラーを優先するかを決定し、接続方法、両面印刷可能性、紙箱の容量でフィルタリングします。基本的に、購入時の落とし穴のほとんどは回避できます。\n","date":"2026-04-01T00:00:00Z","permalink":"https://www.knightli.com/ja/2026/04/01/%E5%AE%B6%E7%94%A8%E6%89%93%E5%8D%B0%E6%9C%BA%E9%80%89%E8%B4%AD%E6%8C%87%E5%8D%97/","title":"家庭用プリンター購入ガイド"}]