ChromeOSって、いつまでサポートされるのかな、と不安に思いつつも、最近、USBキットを発売らしいので、まだしばらくは安心。ということでChromeOSを古いPCに入れました。
イメージのダウンロードが若干分かり難かった。こちらのヘルプから進みます。
このサイトから「イメージをダウンロードする。」に進みインストーラーイメージのリンクからダウンロードします。
Windows環境でインストール用のUSBドライブ作成にはRufusを使いました。
あとは、USBドライブをインストール対象のPCに入れて再起動。
方眼紙Excel（紙/神Excel）」からのデータ抽出は、その使い方の多様さゆえに、単純な表形式変換では困難を極めます。しかし、最近ではDoclingなどにより、生成AIと親和性の高い抽出が現実的になってきました。
セルの結合を多用したシートは特に難易度が高いですが、VLM（視覚言語モデル）を活用し、画面キャプチャをそのまま入力するだけでも、かなりの精度で情報を抽出できます。ただし、VLMには画像サイズの制限があり、巨大なシートでは文字や罫線が潰れて精度が低下するほか、再利用し難いという課題もあります。
そこで、方眼紙Excelからの情報抽出にチャレンジしました。Excelの実体であるOffice Open XMLを直接解析し、構造を再構築する手法を採りました。具体的には、罫線情報を保持したままHTML形式に変換してLLMに渡すことで、正確な構造化を実現しています。さらに、LibreOfficeによる画像レンダリングを併用してLLMの理解を補完させます。ただし、画像レンダリングは、方眼紙エクセルに関しては大きな効果はありませんでした。だいたい、HTMLで表現できているためだと考えています。
上記の考えで作成したパイプライン：
例えば、以下の様なシートを変換してみます。
Markdown(key Value形式）
# 報告書
- **title**: 業務完了報告書
## reporter
- **name**: 山田 太郎
- **date**: 2026-03-02
## content
- **summary**: 本日、プロジェクトAの主要なマイルストーンを達成しました。
### details
- XMLマップ抽出ロジックの構築
- Gemini 2.0 Flashによる構造化テスト
## work_details
- id: 1, task_name: 環境構築, duration_hours: 2
- id: 2, task_name: コード実装, duration_hours: 4.5
- id: 3, task_name: テスト, duration_hours: 1.5
YAML形式
title: 業務完了報告書
reporter:
name: 山田 太郎
date: 2026-03-02
content:
summary: "本日、プロジェクトAの主要なマイルストーンを達成しました。"
details:
- "XMLマップ抽出ロジックの構築"
- "Gemini 2.0 Flashによる構造化テスト"
work_details:
- id: 1
task_name: 環境構築
duration_hours: 2
- id: 2
task_name: コード実装
duration_hours: 4.5
- id: 3
task_name: テスト
duration_hours: 1.5
gemini-3.1-flash-lite-previewを使って、巨大な方眼紙エクセルでも試してみましたが、無事にそれらしい出力が得られました。ちょっとした工夫ですが、有効でした。
まだ、細部が雑ですが、XML解析で対応できる範囲も分かったので収穫でした。
Doclingは各種ドキュメントからの生成AI向け情報抽出が可能です。IBMのチームが開発しています。現在も開発は活発です。PDF, DOCX, PPTX, XLSXなど多様なフォーマットに対応している優れものです。このDoclingでお好みのMarkdownの形式にできるようにしてみました。
数表ならいざ知らず、表組してある日本語文書では複雑な構造となっているケースが多い。縦横にセル結合してあるような奴です。それをMarkdownに変換しようとすると、GitHubのMarkdown表形式では表現力が不足します。それを補うためHTML形式で出力するように固定にします。図もついでにリンク埋め込みにします。
経産省が公開している表組の文書をMarkdownにしてテストをし利用できそうなレベルでmarkdown化できました。人間が見ても分かり難いお役所的高度構造化表組文書を生成AIで利用しやすく、かつ、投入データ(markdown)を人間が見ても分かるのは便利でした。といっても、もとの表組文書そのものが、理解しにくいという根本的に改善してほしい。
DoclingではHTML形式の表埋め込みの実装も進んでいるので、そのうち、オプションだけでよくなるのでしょう。また、画像データを用いてOCRをする場合は、日本語性能がよいOCRで予め文字埋め込みPDFとしておいた方が良いかも。force_backend_text=Trueとしておけば、埋め込みを優先してくれます。
チャートの読み取りなどなど、これからもDoclingには実装が予定されているようです。汎用的なVLLMをOCR代わりに使うのはお手軽ですが、モデル固有の制限もあります。結構なページ数のものを一気にできないこともあります。
他にもアイデアが出てきたので、継続的に神エクセル、文書エクセルにチャレンジしてみます。
簡単なプレゼンの場合、手元のMarkdownのメモをそのまま投影すればいいことも多いですよね。そこで、Sunwood-ai-labs Makiさんが作成されたMarp Editable UI にLLMによる自動生成支援機能を追加し、数式、Mermaid図も対応させることにチャレンジしました。ざっくりとしたプレゼンはできますし、LibreOfficeを利用できるようにすれば、なんとかパワーポイントにも出力できます。
優秀なサービスが他にあると思いますが、実用を兼ねてpython以外のコーティングにもチャレンジしてみました。
Antigravityを主として使ってコーティングを進めました。ウインドウの仕切りを可動できるようにしつつ、他の機能を盛り込もうとすると、あっちの機能を足すと、ウインドウの可動が効かなくなったり、コツをつかむまで苦労しました。ダラダラとやりとりすると、コンテキストを圧縮するようなときに重要な内容を忘れてしまいます。今現在は、AntigravityよりもGemini CLIの方が安定感がある気がします。
PyxelはPython 向けのレトロゲームエンジンです。道具もそろっていてPythonを利用したゲームが作成できます。ブラウザ上でも動作する優れものです。このPyxelにAgent Skillsがあったら、もっと気軽にゲームが出来るんじゃないでしょうか。Gemini CLIを使い、Agent Skillのお勉強もかねて作成しました。加えて、Pyxel 2.7.8で3D描画が強化されたので、スキルに簡単に落とし込んでみました。2.7.9で若干の変更があったため、そちらに対応するように構築しなおしました。
Pyxelのレポジトリ：
テストとして、ゲームを作ってみました。音楽やタイトル画面もGemini君に指示して作りました。SKILLってどうレポジトリに上げると良いのか分からなかったので、.agent配下をごっそりpushしました。
スキルを更新しながら作ると、今回Web(WASM)用の出力時にimportのエラーで困ったのですが、それも、スキルに書いておくと変換時に自動的に注意してくれるのは助かります。
Skillsと作ったゲームのレポジトリ：
サンプルゲーム画面：
VS Codeの機能拡張も出ていて便利。ただ・・・エラーが実行画面に出るのが難点です。ターミナルに出ればGemini君にエラーメッセージをそのまま投入できるのですが・・・。
NDLOCR-Liteは軽量な日本語OCRです。colabで試してみたらいい感じでした。REST APIとして実装してみました。APIができたので、いろんなプログラムから呼べるので便利です。
`/v1/ocr` で同期処理に加え、非同期処理もサポート。負荷テストも簡単に実施しました。落ちたりしませんでした。
APIを簡単にテストできるようにstreamlitによるUIを実装しました。画像をupload出来るほか、オリジナルのレポジトリのテスト用画像データを利用することも出来るようにしました。
色々と使い手がありそうです。
公開していただきありがとうございます。
NDLOCRは国立国会図書館がCC BY 4.0ライセンスで公開したOCRです。CPUでも動作する軽量なモデル。有難くお試しします。モデルの再学習及びカスタマイズについての開発者向け情報もあって、今後バリエーションも増えるのかもしれません。
Colab(CPU)環境という前提で10から30秒/画像での処理が可能でした。平均して19.5秒程度。家庭でも十分に利用できそうですね。GPU利用だったら爆速でしょう。
ライセンスはCC BY 4.0です。
LibreChatでCode Interpreterをローカルで動作をさせたくてお試しましたが、可能性ありそうだなというレベルでした。真面目に利用しようとすると、ファイルをコンテナへのファイルアップロード機能など不足している機能など全然だめです。
エージェントを利用するには、こういう技術は必要になってくるでしょうから、お勉強代わりに作りこみます。LibreChatの完成度の高い機能群は魅力的ですし、テストもしやすいので実装を続けてみます。
Libre Chat経由でファイルをコンテナ内とのupload/downloadがうまく行かず苦労しました。リバースプロキシ入れてみたりして無駄な遠回りをしました。最終的にはリバースプロキシは不要でした。Antigravityとの共同作業ではブラウザを開いてもupload用のダイヤログは補足できないため、手順を確認してログを監視しておいてもらう、という流れでBug出ししていきました。独りで作業すると、流れちゃってて気が付かないところを監視させるのは良い感じです。
Kaggleのstore_sales.csvを利用してテストを実行しました。モデルはgemini_flash-latestを用います。importせずに進めようとしたのでプロンプトに仕込めばいいでしょう。利用できるライブラリリストも明示的に入れるか、requirementファイルもコンテナ内にあるので入れ込む等々。
最後の出力
ご提示いただいた `store_sales.csv` を用いて、時系列分析（データ前処理、リサンプリング、移動統計量、成分分解、および周波数解析）を実施しました。
### 分析結果の要約と知見
1. **強い週次周期性（Weekly Seasonality）**:
* **FFT（高速フーリエ変換）解析**の結果、最も支配的な周期は **約7.02日** であることが確認されました。これは小売売上における典型的な「曜日による変動」を強く示唆しています。
* **自己相関（Autocorrelation）** プロットでも、ラグ 7, 14, 21, 28日において顕著なスパイクが見られ、1週間ごとのパターンが非常に安定していることがわかります。2. **トレンドとボラティリティ**:
* 7日間の移動平均（Moving Average）を算出することで、日々の細かい変動（ノイズ）を除去した中長期的な売上推移が可視化されました。
* 移動標準偏差（Rolling Std）により、売上の「ばらつき」が時期によって変動していることが確認できます。特定の期間にばらつきが大きくなる場合、キャンペーンや大型連休の影響を強く受けている可能性があります。3. **外部要因の影響（プロモーションと休日）**:
* **プロモーション（Promo）**: 実施時の平均売上は約 **252.0** であり、非実施時（約 222.5）と比較して約 **13% の売上向上**が見られます。
* **休日（Holiday）**: 休日時の平均売上は約 **263.5** であり、通常時（約 224.4）に比べ約 **17% 高い**結果となりました。4. **リサンプリングによる概観**:
* 日次データを月次（Monthly）に集約することで、季節ごとの成長性や落ち込みを把握しやすくなりました。---
### 詳細解析プロセスと可視化
以下に実施したコードの内容と、生成されたグラフの解説をまとめます。
#### 1. データの前処理とリサンプリング
`pd.to_datetime` を用いて日付列を変換し、インデックスに設定しました。月次集計 (`resample('ME').sum()`) を行うことで、月ごとの売上パフォーマンスを算出しました。#### 2. 移動統計量の計算
7日間の窓関数（Window）を用いて、トレンド（移動平均）と不確実性（移動標準偏差）を算出しました。これにより、短期的なスパイクに惑わされずに全体の勢いを捉えています。#### 3. 時系列の成分分解（簡易実装）
移動平均を「トレンド」成分とし、そこから曜日ごとの平均偏差を「季節性」成分として分離しました。
* **トレンド**: 長期的な売上の増減。
* **季節性**: 曜日による売上の規則的な変動（例：週末に売上が伸びる等）。
* **残差（Residual）**: トレンドや季節性で説明できない、突発的な変動。#### 4. 周波数解析（SciPy: FFT & 自己相関）
SciPy の `fft` を用いてパワースペクトルを計算し、卓越した周波数を特定しました。また、`scipy.signal.correlate` を用いて自己相関を算出し、過去の売上が将来の売上にどのように関連するかを定量化しました。### 生成された図表の説明
* **combined_analysis.png**:
* 1段目: 元データと移動平均・標準偏差（売上の全体像）。
* 2段目: 抽出されたトレンド（平滑化された推移）。
* 3段目: 曜日ごとの平均的な売上偏差（週次サイクル）。
* 4段目: FFT 振幅スペクトル（周期性の特定）。
* 5段目: 自己相関プロット（ラグごとの相関）。```python
# 分析結果の統計値 (一部抜粋)
- 日次平均売上: 2284.35
- プロモーション効果: 有(251.97) / 無(222.47)
- 休日効果: 有(263.52) / 無(224.36)
- FFT検出周期: 7.02 日
```これらの知見から、この店舗の売上予測モデルを構築する際には、**曜日ダミー変数**および**プロモーション/休日の有無**を特徴量として含めることが非常に有効であると判断できます。
Qwen3, GPT-OSSの日本語チューンナップモデルであるSwallowが公開されました。QwenもGPT-OSSといったベースも良い出来なので期待しますよね。Colab L4環境で動作させてみました。
Colabでどうやって動かそうかと考えましたがvLLMを利用します。日本語の性能は問題なさそうです。また、情報抽出タスクなどもやらせてみましたが、安定した出力が得られたように感じています。様々なタスクに利用できそうな性能です。これらを、さくらのAI Engineで安くサービス欲しいですね。
guffとした場合にどこまで精度がでるのかは気になるところですが、使いどころは沢山あるのでないでしょうか。
# 出力例
User: アニメ「魔法少女まどか☆マギカ」の中で、一番かわいいキャラクターは誰だと思いますか？主観で構いませんので、その理由も教えてください。
### ReasoningThe user asks: "In the anime '魔法少女まどか☆マギカ', who is the cutest character? It's subjective, give reasons." This is allowed. No disallowed content. Provide answer in Japanese. Provide subjective opinion.
--------------------### Response
個人的には、**鹿目まどか**が一番かわいいキャラクターだと思います。その理由は次の通りです。1. **純粋さと無邪気さ**
まどかは、最初は普通の高校生で、魔法少女になるきっかけは「自分の願いを叶えてほしい」だけというシンプルな動機です。その純粋さが、どこか子どもっぽく、無邪気に見えるため、視覚的にも「かわいい」印象を与えます。2. **可愛らしい外見**
長い黒髪に、シンプルで白いトップス、そして大きな瞳が特徴です。特に、魔法少女に変身したときの白いワンピースと大きなリボンは、まさに「かわいさ」の象徴です。3. **成長と変化の過程**
まどかは、最初は弱々しい魔法少女ですが、仲間や自分の信念に支えられながら少しずつ強さと自信を手に入れていきます。その変化の過程で見せる「頑張る姿」や「涙を流す姿」も、かわいさを引き立てます。4. **感情表現が豊か**
まどかは喜び・悲しみ・恐れ・決意といった感情を表情豊かに表現します。特に、仲間と再会したときの涙や、最後のシーンでの静かな微笑みは、観る人の心に強く響き、かわいさを感じさせます。5. **ファンからの人気**
実際、まどかは「魔法少女まどか☆マギカ」のファンの中で最も支持されているキャラクターのひとつです。その人気は、上記の「純粋さ」や「可愛らしさ」に裏打ちされていると考えられます。もちろん、他にも「成海ねね」や「星井美希」など、魅力的なキャラクターはたくさんいますが、まどかの「純粋さと成長」のストーリーが、総合的に見て一番「かわいさ」を引き立てていると感じます。
成海ねね・・？星井美希・・・？以外は良い感じの答えでしょうか。
その他の結果は以下のリンクから。
日本語APIで軽量さと精度のバランスが良く、prefix含み8k tokensを入力できるruri-v3は、embeddingモデルととても便利に使っています。modernBERTベースでSentencepiceをトークナイザーとして用いています。大変便利なので、embedding APIサーバーを作ってみました。今回は、利用目的から負荷テストまで行いました。なお、LAN内とかdocker network内での利用レベルを想定しています。
とりえず作って負荷テストをすると0.01～0.1%程度の頻度でエラーがでます。ざっくり使うだけならば問題ないレベルかもしれませんが、今回は追究します。Jules君とAntigravityを組み合わせて進めました。まず、Jules君に問題点の抽出をしてもらいPRを出してもらう。次にAntigravityでPRを検証しながらマージしていくといった手段です。
今回の場合は大量のテキストデータを利用するケースを考えていたので、エラーが起きるとやり直しがメンドイです。そこで、シツコクテストを繰り返しましたが、Jules君とAntigravity様が頑張ってくれました。
ruri-v3やembeddingのAPIや使い方を調べて、具体的な指示がvibe codingでは重要だと再認識しました。それに、勉強してそれをすぐに実装できるのは有難いです。調査や実装の要件を考えながらScrap and Build。楽しいですね。
Difyでテストしたら、問題なく動作しました。
完成品：
