2026/04/13

最近、Excel で選択したセルの内容を Ollama で要約・添削できる Add-in を作ってみた

最近、Excel で選択したセルの内容を Ollama で要約・添削できる Add-in を作ってみた。

正直なところ、想定外の落とし穴がいっぱいあった。特に「ローカルネットワーク別 PC の Ollama に、Excel Add-in から安全にアクセスする」という部分が、予想以上に複雑だった。その試行錯誤プロセスを記録しておく。


背景:なぜこんなもの作ったのか

仕事で長めの文章を扱うことが多い。メール、レポート、提案書とか。

最初は ChatGPT API で要約・添削をやってみたけど、3 つの理由でやめた:

  1. データを外に出したくない - 機密文書を API に送るのは避けたい
  2. API コストが地味に積もる - 毎日使うと月額が結構かかる
  3. レスポンス待ちが遅い - 社内 LAN 上なら圧倒的に速い
そこで目を付けたのが Ollama。ローカルネットワーク別 PC で Ollama を建てて、そこに直接アクセスできれば、データも保護できるし、レスポンスも速い。

「Excel から直接使えたら最高だな」と思いついて、Add-in を作り始めたのが始まり。


技術構成

実装してみた構成は以下:

【Excel Add-in】
  ↓ HTTPS でロード
https://localhost:8888(React UI の配信)
  ↓ HTTP リクエスト
【Go バックエンド】(localhost:8888)
  ↓ ローカルネットワーク経由
【Ollama API】(http://172.19.10.10:11434)

バックエンド: Go(標準 net/http パッケージ)

  • シンプルに HTTP サーバーを立てるだけなので、フレームワークは不要だと判断
  • 自己署名証明書での HTTPS 対応

フロント: React

  • Office JavaScript API で Excel セルの読み書き
  • Go API への HTTP 通信

Ollama

  • ローカルネットワーク別 PC 上で実行
  • セルの内容を送信 → 要約・添削結果を取得

予想外の落とし穴:Excel Add-in の HTTPS 必須ポリシー

実装し始めてすぐにぶつかったのが、Excel Add-in は HTTP ではなく HTTPS が必須という制約。

「localhost で動かすんだから HTTP でいいか」と思ってた。甘かった。

さらに複雑だったのが、Ollama が ローカルネットワーク別 PC にあること。

構図:
  PC A(Excel を使ってる)
    ↓
  自分の PC(Go + React のサーバー)
    ↓ ローカルネットワーク
  PC B(172.19.10.10 に Ollama が動いてる)

やりたいこと:

  • Excel Add-in の UI(HTML/React)を自分の PC から HTTPS で配信
  • Add-in から Ollama(別 PC)に HTTP でアクセス

問題:

  • Excel Add-in は HTTPS 配信が必須だけど、自己署名証明書では「信頼されていない」と判定される
  • 別 PC の Ollama にはネットワーク経由でアクセスする必要がある

解決策 1:オレオレ証明書を localhost で動かす

まず自己署名証明書を生成した。

openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes \
  -subj "/CN=localhost"

この証明書と秘密鍵で、Go の net/http サーバーを立ち上げる。

package main

import (
    "net/http"
)

func main() {
    // ハンドラーを登録
    http.HandleFunc("/api/summarize", handleSummarize)
    http.HandleFunc("/api/proofread", handleProofread)

    // HTTPS で起動(自己署名証明書使用)
    http.ListenAndServeTLS(":8443", "server.crt", "server.key", nil)
}

これで https://localhost:8443 で HTTPS サーバーが起動。

ただし、ここまでではまだ不十分。Excel Add-in のコンテキストでは、この自己署名証明書が「信頼されていない」と判定される。


解決策:自己署名証明書 + ネットワークルーティング

ここが工夫の見せどころ。

2 つのポイントで解決した:

  1. localhost で自己署名証明書を使った HTTPS サーバー起動 - Excel Add-in の HTTPS 必須要件を満たす
  2. Go バックエンド - HTML/React を配信しつつ、Ollama への API リクエストを中継
【構図】
Excel Add-in
  ↓ HTTPS でロード
https://localhost:8888
  ↓ HTML/React の配信 + API エンドポイント
【Go サーバー】
  ├─ /(HTML/React UI を配信)
  └─ /api/summarize, /api/proofread(Ollama に転送)
    ↓ HTTP でローカルネットワーク経由
http://172.19.10.10:11434
  ↓
【Ollama API】

実装

まず自己署名証明書を生成。

openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes \
  -subj "/CN=localhost"

Go のサーバーコード:

package main

import (
    "net/http"
    "net/http/httputil"
    "net/url"
)

func main() {
    // Ollama API へのリバースプロキシを設定
    ollamaURL, _ := url.Parse("http://172.19.10.10:11434")
    reverseProxy := httputil.NewSingleHostReverseProxy(ollamaURL)

    // HTML/React UI を配信
    fs := http.FileServer(http.Dir("./public"))
    http.Handle("/", fs)

    // /api/generate は Ollama に中継
    http.HandleFunc("/api/generate", func(w http.ResponseWriter, r *http.Request) {
        reverseProxy.ServeHTTP(w, r)
    })

    // HTTPS で起動(自己署名証明書)
    http.ListenAndServeTLS(":8888", "server.crt", "server.key", nil)
}

React 側から Ollama API を呼び出すときは、相対パス /api/generate を使う。

// React コンポーネント
const handleSummarize = async (cellContent) => {
    const response = await fetch('/api/generate', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
        },
        body: JSON.stringify({
            model: 'llama2:7b',
            prompt: `要約してください:\n\n${cellContent}`,
            stream: false
        })
    });

    const result = await response.json();
    return result.response;
};

重要なポイント:

  • localhost:8888 で自己署名証明書を使った HTTPS サーバーを起動
  • Excel Add-in のセキュリティ要件(HTTPS 配信)を満たす
  • React は相対パス /api/generate で Ollama に通信(実際には Go バックエンドが仲介)
  • Go バックエンド内で、localhost から 172.19.10.10 へのネットワークルーティングを実現
  • シンプル:プロキシツール不要で、Go だけで実装完結

セルを選択→要約・添削:実装の流れ

実装が決まったら、次は実用機能。

Excel で文章が入ってるセルを選択して、「要約」「添削」ボタンを押すと、Ollama で処理してセルに結果を返す。

流れ:

  1. セル選択時のイベント取得
await Excel.run(async (context) => {
    const cell = context.application.getSelectedData();
    // セルの内容を取得
});
  1. Go API に送信
const summarized = await fetch('https://localhost:8888/api/summarize', {
    method: 'POST',
    body: JSON.stringify({ text: cellContent })
});
  1. Ollama から要約結果を取得
  • モデルはデフォルトで llama2:7b を使用
  • プロンプトエンジニアリングで「要約」「添削」を区別
  1. 結果をセルに書き込み
await Excel.run(async (context) => {
    context.worksheets.getActiveWorksheet()
        .getRange("A1")
        .values = [[result]];
});

実装時の工夫:

  • ローディング表示 - Ollama はレスポンスに数秒かかるので、「処理中...」を表示
  • エラーハンドリング - ネットワーク接続や Ollama が落ちてる場合の対応
  • タイムアウト設定 - 長すぎる文章は処理に時間がかかるので、上限を設ける
  • プロンプト最適化 - 同じモデルでも「要約」「添削」でプロンプトを変える
// 要約用プロンプト
func getSummarizePrompt(text string) string {
    return fmt.Sprintf(
        "以下のテキストを簡潔に要約してください。箇条書きで3点まで。\n\n%s",
        text,
    )
}

// 添削用プロンプト
func getProofreadPrompt(text string) string {
    return fmt.Sprintf(
        "以下のテキストの文法、表現、敬語を確認して、改善案を提示してください。\n\n%s",
        text,
    )
}

実際に使ってみて

完成して 1 ヶ月ほど使ってみた感想。

便利だったこと:

  1. データが外に出ない - 機密文書を扱うときは本当に安心。API に送ってる時間を気にしなくていい
  2. レスポンスが速い - ローカルネットワーク経由なので、ChatGPT API より圧倒的に高速。待ち時間がストレスにならない
  3. コストがゼロ - Ollama はローカル実行なので追加コストなし。PC のリソース(GPU)を使ってる分だけ

予想外だったこと:

  • 要約の質が思ったより良い - llama2:7b で十分実用的。わざわざ大型モデルに乗り換える必要がない
  • 添削より要約の方が使用頻度が高い - 最初は「添削機能メインで作ろう」と思ってたけど、実用では「要約」がメイン用途に
  • 複数人での利用が想定より難しい - 自分の PC でプロキシを立ててるので、他の PC からはアクセスできない。チーム展開するなら、プロキシを別サーバーに移す必要があった

今後の改善案:

  • Ollama の複数モデル対応 - llama2 以外の軽量モデル(mistral など)も選べるようにしたい
  • Web UI での設定画面 - 今は Go コード内でハードコードしてる設定を、UI で変更できるように
  • ローカルプロキシをサーバー化 - チーム利用を想定して、プロキシを別サーバーに移す

技術的な学び

このプロジェクトで学んだことが 3 つ。

1. Excel Add-in のセキュリティ要件は思ったより厳しい

Excel が HTTPS・自己署名証明書・CORS まで厳密にチェックする。SPA(Single Page Application)の世界と違って、企業向けアプリケーションの厳格さを感じた。

2. ローカル接続は「仲介役」として超有効

別ネットワークにある Ollama にアクセスする時、直接アクセスではなくローカルサーバー経由にすることで、セキュリティと利便性のバランスが取れた。

3. ローカル LLM の強さ

API の待ち時間がゼロに等しく、コストもかからない。確度は ChatGPT より落ちるかもしれないが、実務用途(要約・添削)には十分。「LLM の大型化よりローカル化の時代が来たのかも」と感じた。


まとめ

「Go + React + Ollama」という組み合わせで Excel Add-in を作った。

最大の工夫は「自己署名証明書 + ネットワークルーティング」という組み合わせで、ローカルネットワーク別 PC の Ollama に安全にアクセスする仕組み。

完成してみると、想定外の利便性があった。特に「データが絶対外に出ない」という安心感と「レスポンスの速さ」は、クラウド API では代替できない価値。

チーム展開や本番運用となると、プロキシのサーバー化やアーキテクチャの見直しが必要だけど、個人ツールレベルなら「自己署名証明書 + ネットワークルーティング」で十分実用的。

ローカル LLM の活用方法は、これからも増えていくんだろうなと思った。

2026/03/31

【緊急】axiosがサプライチェーン攻撃に遭遇:汚染バージョン(1.14.1 / 0.30.4)と今すぐ取るべき対策

2026年3月31日、npm パッケージ「axios」がサプライチェーン攻撃の被害に遭った。

単なる「脆弱性が見つかった」ではなく、axios のメンテナアカウントが侵害されて、悪意あるバージョンが npm に直接公開された。つまり、ダウンロードして npm install しただけで、マルウェアが仕込まれる可能性がある。

この記事は、「うちの環境で使ってるけど、どうしたらいい?」という判断フローを書いておく。


事件の概要

何が起きたのか

axios のメンテナアカウント(複数疑い)が侵害され、以下の 2 つのバージョンが悪意あるコードを含んで npm に公開された:

  • axios@1.14.1(最新安定版)
  • axios@0.30.4(レガシー版)

どちらも、同じ手口でマルウェアが混入していた。

どのくらい危険か

めっちゃ危険。理由:

  1. axios は超ポピュラー - JavaScript/Node.js 開発で最も使われている HTTP クライアントライブラリ
  2. 直接実行される - npm install 時に postinstall フック で自動実行
  3. 複数プラットフォーム対応 - Windows/Mac/Linux すべてに対応したマルウェア

実際に axios のダウンロード数は週 2000 万超。2~3 時間の公開期間でも、数千~数万の開発者が被害に遭った可能性がある。


技術的な詳細

マルウェアの動作

npm install 時に postinstall フック が実行され、以下の処理が起きる:

  1. プラットフォーム判定 - OS(Windows/Mac/Linux)を自動判定
  2. マルウェア配置 - 各 OS の隠蔽しやすい場所に RAT(リモートアクセストロージャン)を配置
  3. C2 サーバーへの接続 - sfrclak[.]com:8000 へ接続
  4. トレース消去 - node_modules から証拠を削除

各 OS でのマルウェア配置先

OS 配置先 特徴
macOS /Library/Caches/com.apple.act.mond キャッシュフォルダに偽装
Windows %PROGRAMDATA%\wt.exe, %TEMP%\6202033.vbs システムフォルダに混在
Linux /tmp/ld.py /tmp に配置(起動時消滅する可能性)

含まれていた悪意あるパッケージ

公式記述では「plain-crypto-js」という偽パッケージ。これが dependencies に追加されて、npm install 時に自動ダウンロード・実行される。


うちは大丈夫?:判断フロー

ステップ 1:package.json / package-lock.json を確認

# 正確な確認方法
grep -E "axios.*1\.14\.1|axios.*0\.30\.4" package-lock.json

もし上記コマンドで何か出たら要注意。

ステップ 2:実際にインストールされているバージョンを確認

npm list axios

出力例:

└── axios@1.14.0

1.14.0 以下、または 0.30.3 以下なら OK。1.14.1 または 0.30.4 なら危険。

ステップ 3:「うちのチームはいつこれをインストールしたのか?」を確認

npm install したのが 3月31日の 2~3 時間の間 だったかどうかで、被害の可能性が変わる。

  • 3月31日より前にインストール: 被害なし
  • ⚠️ 3月31日 12:00~15:00 GMT 付近でインストール: 被害の可能性あり
  • 3月31日 15:00 以降でインストール: 被害なし(既にパッチ済み)

リスク評価:うちは被害に遭ったのか?

ケース 1:インストールしたけど実行環境が本番ではない(社内 PC のみ)

リスク度: 中~高

対応:

  1. 該当の PC のマルウェアをスキャン(下記参照)
  2. API キー・パスワードをすべてローテーション
  3. git commit / push のログをチェック(悪意あるコードがコミットされていないか)

ケース 2:本番環境で実行中

リスク度: 超高

すぐに以下を実行:

  1. サーバー再起動
  2. 認証情報のすべてをローテーション(API キー、DB パスワード、SSH キーなど)
  3. アクセスログ確認sfrclak[.]com への外部通信がなかったか)
  4. セキュリティ監査(外部セキュリティ企業に委託検討)

ケース 3:Docker / CI/CD パイプラインで npm install を実行

リスク度: 超高

  • Docker イメージが作成されて、本番環境にデプロイされている場合
  • GitHub Actions などの CI パイプラインで実行してた場合
  • → 該当期間の全デプロイを疑う

対応:

  1. 該当期間の全デプロイを一覧化
  2. 本番環境から当該バージョン削除
  3. 全認証情報ローテーション

すぐにやるべきこと:修復手順

ステップ 1:axios をダウンロードグレード

npm install axios@1.14.0 --ignore-scripts

なぜ --ignore-scripts が必要か

  • もし 1.14.1 がまだキャッシュに残ってたり、中途半端な状態だと危険
  • グレードダウン時も postinstall フック を無視して安全にする

ステップ 2:node_modules の手動確認

# 疑わしいファイルを探す
find node_modules -name "plain-crypto-js" -type d
find node_modules -name "*.vbs" -o -name "*.exe" -o -name "*.py"

見つかったら、即座に削除:

rm -rf node_modules/plain-crypto-js
npm ci  # package-lock.json から再インストール

ステップ 3:マルウェアスキャン(PC にインストールされている場合)

Windows:

Start-MpScan -ScanType FullScan

macOS:

# マルウェアバイトスキャン推奨
# https://www.malwarebytes.com/mac から Malwarebytes ダウンロード・実行

Linux:

sudo freshclam  # パターンアップデート
sudo clamscan -r /tmp /home /root --remove

ステップ 4:全認証情報のローテーション

感染可能性がある環境では、以下をすべてローテーション:


本番環境への影響判定

チェックリスト

すべて「Yes」に近いなら、セキュリティ監査推奨。


実装側の判断:パッケージアップデートはいつする?

axios の対応タイムライン:

バージョン リリース 判定
0.30.3 以下 2026/3/31 18:00 ✅ 安全
1.14.0 以下 2026/3/31 18:00 ✅ 安全
1.14.1 2026/3/31 12:00-15:00 ❌ 危険
0.30.4 2026/3/31 12:00-15:00 ❌ 危険
1.14.2 以上 2026/3/31 15:00 ✅ パッチ済み
0.30.5 以上 2026/3/31 15:00 ✅ パッチ済み

推奨

  • 本番環境: 1.14.2 以上 または 0.30.5 以上 に即座にアップデート
  • 開発環境: 余裕があれば同じく最新版へ

今後のためのセキュリティ対策

npm パッケージ監視ツールの導入

# npm audit で定期チェック
npm audit

# dependabot で自動 PR 生成(GitHub)
# Settings → Code security and analysis → Enable Dependabot

CI パイプラインでのセキュリティスキャン

# npm audit を CI に組み込む
npm audit --audit-level=moderate

package-lock.json の厳密管理

# 本番環境では必ず --frozen-lockfile を使う
npm ci --frozen-lockfile
# 決して npm install を使わない

最後に:この事件が教えてくれること

サプライチェーン攻撃は「あり得ない」ではなく「あり得る」。

axios は信頼性の高いパッケージだが、それでも被害に遭った。理由は、人気が高いがゆえに、攻撃者にとって「おいしいターゲット」だったから。

対策:

  1. すべてのパッケージを信用しない - npm audit を常態化
  2. 本番環境を隔離 - 必ず --frozen-lockfile を使う
  3. credentials の定期ローテーション - 3~6ヶ月ごと
  4. ネットワークログの監視 - 不審な外部接続を検出

2026 年も、サプライチェーン攻撃の脅威は続く。

2026/03/26

SSL証明書の有効期限短縮ショック…手動更新の限界と自動化へ

CA/Browser Forum の新ルール:2026年から始まる SSL 証明書の有効期限の段階的短縮化。

最終的には 2029年に 47 日 という極めて短い有効期間になる。これまで「年 1 回更新」で済んでたやつが、近い未来「月複数回更新」になる可能性がある。

正直、手動管理では確実に破綻する。この記事は、「うちのチーム、どう対応すればいい?」という実装判断を書いておく。


タイムラインの全貌

CA/Browser Forum が定めた段階的短縮化

時期 有効期限 管理頻度目安 影響度
現在(2026年3月まで) 398 日 年1回更新
2026年3月15日~ 200 日 年1~2回更新
2027年3月15日~ 100 日 年3~4回更新
2029年3月15日~ 47 日 月複数回更新 超高

2029年の恐怖:47日制限とは

47日という期間は、現在の管理方法では実質的に自動化が必須を意味する。

なぜなら:

  • 人間が「そろそろ更新しようか」と判断→実行 → 検証 → デプロイ
  • この一連が確実に完了するまでに、確実に 1~2週間かかる
  • 47日 - 2週間 = 残り約5週間の余裕
  • その間に他の作業が入ると、簡単に「あ、更新忘れた」になる

問題の本質:「手動管理の破綻」

ケース 1:小規模チーム(1~3人)

現状

  • 証明書が 1~3個
  • 年1回のリマインダーで更新

2029年以降

  • 証明書が同じ数でも、更新頻度が 約 9 倍
  • 月に複数回、毎回「更新→検証→デプロイ」の手作業
  • 誰か 1人が退職したら、知識が失われてヤバい

結果:確実に誰かが忘れる → SSL エラー → サービス停止 → 信用喪失

ケース 2:中規模チーム(複数サーバー、複数ドメイン)

現状

  • 証明書が 10~20 個
  • スプレッドシートで管理

2029年以降

  • 月に 10~20 個 × 複数回の更新作業
  • 手作業では追いつかない
  • ミスの確率が指数関数的に増加

結果:管理が混乱 → 本番環境で SSL エラー → 顧客影響

ケース 3:大規模企業(複数部門、複数国)

現状

  • 証明書が 100 個超
  • 既に何かしらの管理システムで対応

2029年以降

  • 手動ステップが多いと管理システム自体がボトルネック
  • 完全自動化への移行が必須

解決策:ACME プロトコルによる完全自動化

根本的な対応:自動更新の導入

2029年の 47 日制限に耐えられる唯一の方法は、ACME プロトコルを使った完全自動更新

ACME とは:

  • Automated Certificate Management Environment
  • Let's Encrypt が提唱した、証明書の自動更新プロトコル
  • OpenSSL コマンドで certbot を使うことが最も一般的

実装方法:Certbot を使った自動更新

ステップ 1:Certbot のインストール

# Ubuntu/Debian
sudo apt-get install certbot python3-certbot-nginx

# CentOS/RHEL
sudo yum install certbot python3-certbot-nginx

# macOS
brew install certbot

ステップ 2:証明書の自動更新設定

# 証明書を取得(初回)
sudo certbot certonly --nginx -d example.com -d www.example.com

# 自動更新の動作確認
sudo certbot renew --dry-run

ステップ 3:cron で定期実行

# root ユーザーで crontab を編集
sudo crontab -e

# 以下を追加(毎日 2:30 に更新試行)
30 2 * * * /usr/bin/certbot renew --quiet && systemctl reload nginx

この設定で:

  • 毎日自動で更新チェック
  • 更新が必要なら自動実行
  • Nginx をリロード
  • すべて無人で完結

メジャーな証明書発行者の ACME 対応

CA ACME サポート URL 推奨度
Let's Encrypt https://letsencrypt.org ⭐⭐⭐⭐⭐
GlobalSign ACME API あり ⭐⭐⭐⭐
DigiCert ACME API あり ⭐⭐⭐⭐
Sectigo ACME API あり ⭐⭐⭐⭐

推奨:Let's Encrypt でテストしてから、有料 CA に移行。


段階的な導入ロードマップ

Phase 1:現状把握(今月)

- ドメイン名 / 発行元 CA / 有効期限 / 更新予定日

- 誰が更新してるのか / どのサーバーが対象か / 更新後の検証手順は

Phase 2:Let's Encrypt で試験運用(1~2ヶ月)

- インストール / 自動更新の動作確認 / 運用手順の整理

- Let's Encrypt の証明書を取得 / 1ヶ月運用してみる / 特に問題ないか確認

Phase 3:段階的な本番環境への展開(2~4ヶ月)

- 更新スクリプトの改善 / 監視・アラート設定 / トラブル対応の経験値を貯める

- 100日制限への対応が必須になる前に

Phase 4:完全自動化(2027年まで)

- ACME ベースの統一管理 / 中央管理ダッシュボード / 異常時のアラート設定


実装時の注意点

1. Let's Encrypt のレート制限

Let's Encrypt は無料だが、制限がある:

  • 週あたり 50 個の新規証明書
  • 1 ドメインあたり 5 個/週

複数ドメインで同時に導入すると、レート制限に引っかかる可能性がある。段階的導入が大事。

2. DNS 検証 vs HTTP 検証

Certbot の検証方法は 2 種類:

方法 特徴 推奨度
HTTP 検証 .well-known フォルダで検証。シンプル ⭐⭐⭐⭐⭐
DNS 検証 DNS レコード追加で検証。ワイルドカード対応 ⭐⭐⭐⭐

通常は HTTP 検証で十分。DNS 検証が必要なのはワイルドカード証明書の場合。

3. 更新スクリプトのテスト

本番環境を止めないために:

sudo certbot renew --dry-run --non-interactive

# このコマンドを cron で定期実行して
# 「更新が失敗していないか」を事前に検知する

4. 監視・アラート設定

ACME 自動化しても「更新に失敗する」可能性はある。例:

  • DNS が一時的に応答しない
  • サーバーのディスク容量が満杯
  • スクリプトのバグ

対策:

30 2 * * * /usr/bin/certbot renew --quiet || \
  mail -s "SSL renewal failed" admin@example.com

コスト評価

導入前(手動管理)

項目 金額 説明
証明書購入費 月 0~10万円 CA による
人件費(更新作業) 月 2~5万円 年1回なら月割り
合計 月 2~15万円

導入後(ACME 自動化)

項目 金額 説明
証明書購入費 月 0~10万円 CA による(Let's Encrypt なら ¥0)
人件費(初期構築) 50~100万円 1 回限り
人件費(運用・監視) 月 1~3万円 異常時対応のみ
合計 初期 50~100万円 + 月 1~13万円

ROI

  • 初期投資が回収できるのは、約 3~6ヶ月
  • 5 年運用なら 年平均で 15~20万円削減

実装チェックリスト

今月やること

来月やること

3ヶ月以内にやること

2027年3月までにやること


最後に:なぜこんなことになるのか?

CA/Browser Forum が証明書有効期限を短縮化した背景:

  1. セキュリティ向上 - 秘密鍵の露出リスクを早期に低減
  2. 自動化の推進 - 手動管理では対応できないレベルに引き上げることで、業界全体の自動化を加速
  3. 脆弱性対応の高速化 - 有効期限が短ければ、脆弱性検出時に「全サーバーの置き換え」が現実的

つまり、業界全体を「手動管理」から「自動化」へ強制的にシフトさせるための施策。

2029年の 47日制限は、もはや「手動では対応不可」という業界の合意。

早めに自動化しておけば、慌てずに対応できる。逆に、2028年になって「あ、対応しなきゃ」って思っても、もう手遅れ。

今から準備しておこう。

2026/03/20

YouTube LiveのチャットだけをAndroidで別画面表示するアプリを作ってリリースした

YouTube LiveのチャットだけをAndroidで別画面表示するアプリを作ってリリースした

テレビやモニターでYouTube Liveを全画面再生していると、ライブチャットが見えなくなります。スマホでYouTubeアプリを開き直しても動画が再生されてしまう。「Live Chatだけをスマホで別画面表示したい」という需要、ライブ配信を見る人なら絶対あると思っていました。そのまま自分で作ってリリースしました。

作ろうと思ったきっかけ

大画面でライブ配信を見ているとき、Live Chatの流れをリアルタイムで追いたいことがよくあります。でもテレビのフルスクリーン表示ではチャット欄が隠れてしまう。スマホでYouTubeアプリを開き直すと動画が二重再生になって邪魔。

既存のアプリを探してみたのですが、ちょうどいいものが見つからなかったので、自分で作ることにしました。シンプルに「URLを登録したらLive Chatだけが表示される」、それだけのアプリです。

アプリでできること

  • YouTube LiveのURLを登録してLive Chatのみをリアルタイム表示する
  • YouTubeアプリのシェアボタンから直接URLを送って登録できる
  • 動画を再生せずチャット画面だけを表示する
  • テレビ・モニターでライブを見ながらスマホでチャットを追える
ポイント

YouTubeアプリのシェアボタン経由で登録できるのが地味に便利です。URLをコピペする手間がなく、見ているライブ配信をそのまま登録してチャット画面を開けます。

使い方

  1. テレビやモニターでYouTube Liveをフルスクリーン再生する
  2. スマホのYouTubeアプリで同じライブ配信を開き、シェアボタンをタップ
  3. 共有先から「ChatTube」を選択
  4. アプリにLive Chatがリアルタイムで表示される

もちろんURLを直接入力して登録することもできます。動画IDだけでも対応しています。

こんな場面で使える

  • ライブ配信をテレビで見ながら、スマホでLive Chatをリアルタイムに追う
  • PC作業中に別モニターでライブ再生しつつ、スマホでチャットだけ確認する
  • 家族と大画面でライブを見ながら、自分だけチャットを追いたいとき
  • 配信者がチャットの反応を別画面で確認しながら配信するとき
セカンドスクリーン活用

テレビのリモコンでYouTubeを操作しているとチャット欄へのアクセスが面倒です。このアプリを使えばスマホをLive Chat専用画面として使えます。

ダウンロード

Android向けに Google Play で公開しています。無料でダウンロードできます(広告あり)。

Google Play で「ChatTube」を見る

不具合・要望があればコメントかレビューで教えてもらえると助かります。使ってみた感想もぜひ。

2026/03/13

LangChainでAI駆動開発を自動化する:要件定義からテストまでフェーズ別エージェント実装ガイド

LangChainでAI駆動開発を自動化する:要件定義からテストまでフェーズ別エージェント実装ガイド

うちのチームに新しいメンバーが入ってきて、「LangChainを使えば開発全部自動化できますよね?」と言い出しまして。気持ちはわかるんですが、そこには大きな落とし穴があります。要件定義で使うべき思考と、テストケースを考えるときの思考は、根本的に違う。それを1つのエージェントに丸投げするとどうなるか——自分で試して痛い目を見ました。この記事では、フェーズごとに専門エージェントを分業させるアーキテクチャをLangChainで実装する方法を、実際に動くコードとともに解説します。

注目ポイント

エージェントはステートレスに設計し、フェーズ間の引き渡しは「ドキュメントオブジェクト」で行うのが安定運用の鍵。コンテキストを引き継ぐのではなく、前フェーズの成果物を次フェーズへの入力として渡す。

なぜ「1エージェント・全工程」は破綻するのか

LangChainのReActエージェントやLCELチェーンを使って「ユーザーの要望を入力したら設計書とコードとテストが出てくる」パイプラインを作ろうとした経験がある方は多いと思います。最初の数回は動く。でも少し複雑な要件を入れた途端、出力が崩れ始める。

原因はシンプルで、LLMのコンテキストウィンドウには限界があるからです。要件定義の議論をしながら、同時に実装コードの詳細まで考えさせると、どちらも中途半端になる。さらに問題なのは、エラーになるのではなく「それっぽい何か」が出力されてしまうこと。これが一番タチが悪い。

よくある失敗パターン

「1つの巨大プロンプトに全フェーズの指示を詰め込む」アプローチ。最初は動いて見えるが、要件が複雑になった瞬間に崩壊する。プロンプトエンジニアリングで解決しようとするより、設計を分けるほうが早い。

全体設計と前提環境

今回実装する構成はこうなります。4つの専門エージェントを順番に実行し、各エージェントの出力をPydanticモデルで型定義した「ドキュメントオブジェクト」として次のエージェントに渡します。

# 全体のフロー
ユーザー入力(要件メモ)
    ↓
RequirementsAgent  → RequirementsDoc(曖昧さリスト・確定仕様)
    ↓
DesignAgent        → DesignDoc(アーキテクチャ・API定義・DB設計)
    ↓
CodingAgent        → CodeDoc(実装コード・ファイル構成)
    ↓
TestAgent          → TestDoc(テストケース・テストコード)

前提環境

pip install langchain langchain-community langchain-core
pip install pydantic ollama

# Ollamaでモデルを起動しておく
ollama run gpt-oss:20b

OpenAI APIを使う場合は langchain-openai に差し替えるだけです。今回はローカルLLM(Ollama)ベースで書きますが、モデル部分は差し替え可能な設計にします。

要件定義エージェント:曖昧さを構造化する

要件定義エージェントの仕事は2つ。ひとつは入力テキストから曖昧な箇所を検出して質問リストを生成すること、もうひとつは確定した仕様を構造化されたオブジェクトに変換することです。

from langchain_community.llms import Ollama
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import JsonOutputParser
from pydantic import BaseModel, Field
from typing import List

# 出力の型定義
class RequirementsDoc(BaseModel):
    ambiguities: List[str] = Field(description="曖昧な点・確認が必要な事項のリスト")
    confirmed_specs: List[str] = Field(description="確定した仕様のリスト")
    constraints: List[str] = Field(description="技術的・ビジネス的制約のリスト")
    summary: str = Field(description="要件の概要(2〜3文)")

class RequirementsAgent:
    def __init__(self, model_name: str = "gpt-oss:20b"):
        self.llm = Ollama(model=model_name, temperature=0.1)
        self.parser = JsonOutputParser(pydantic_object=RequirementsDoc)
        self.prompt = ChatPromptTemplate.from_messages([
            ("system", """あなたはシニアのシステムアナリストです。
入力された要件テキストを分析し、以下を必ずJSON形式で出力してください。
- 定義が曖昧で確認が必要な項目
- 確定した仕様
- 技術的・ビジネス的制約
- 要件の概要

{format_instructions}"""),
            ("human", "以下の要件を分析してください:\n\n{requirements_text}")
        ])

    def run(self, requirements_text: str) -> RequirementsDoc:
        chain = self.prompt | self.llm | self.parser
        result = chain.invoke({
            "requirements_text": requirements_text,
            "format_instructions": self.parser.get_format_instructions()
        })
        return RequirementsDoc(**result)
設計のポイント

temperature=0.1 に設定するのがミソ。要件定義は「創造性」より「網羅性・一貫性」が重要なので、低めのtemperatureで安定した出力を得る。

設計エージェント:仕様書からアーキテクチャを生成する

設計エージェントは RequirementsDoc を受け取り、アーキテクチャ案・API定義・DBスキーマを出力します。ここでのポイントは、前フェーズの「曖昧さリスト」も一緒に渡すこと。曖昧なままの仕様を無視した設計を出力させないためです。

class DesignDoc(BaseModel):
    architecture: str = Field(description="アーキテクチャの説明(テキスト)")
    api_endpoints: List[dict] = Field(description="APIエンドポイント定義リスト")
    db_schema: List[dict] = Field(description="DBテーブル定義リスト")
    tech_stack: List[str] = Field(description="使用技術スタック")
    assumptions: List[str] = Field(description="設計上の前提・仮定(曖昧仕様への対応)")

class DesignAgent:
    def __init__(self, model_name: str = "gpt-oss:20b"):
        self.llm = Ollama(model=model_name, temperature=0.2)
        self.parser = JsonOutputParser(pydantic_object=DesignDoc)
        self.prompt = ChatPromptTemplate.from_messages([
            ("system", """あなたはシニアのソフトウェアアーキテクトです。
確定仕様と制約に基づいてシステム設計を行い、JSON形式で出力してください。
曖昧な仕様については、設計上の前提として assumptions に明記してください。

{format_instructions}"""),
            ("human", """確定仕様: {confirmed_specs}
制約: {constraints}
曖昧な点(前提として扱う): {ambiguities}
要件概要: {summary}""")
        ])

    def run(self, req_doc: RequirementsDoc) -> DesignDoc:
        chain = self.prompt | self.llm | self.parser
        result = chain.invoke({
            "confirmed_specs": "\n".join(req_doc.confirmed_specs),
            "constraints": "\n".join(req_doc.constraints),
            "ambiguities": "\n".join(req_doc.ambiguities),
            "summary": req_doc.summary,
            "format_instructions": self.parser.get_format_instructions()
        })
        return DesignDoc(**result)

実装エージェント:設計書をコードに落とす

実装エージェントは DesignDoc のAPIエンドポイント定義とDBスキーマを受け取り、コードを生成します。全体を一度に生成しようとするとコンテキスト超過するので、エンドポイントごとに分割して呼び出す設計にしています。

class CodeDoc(BaseModel):
    files: List[dict] = Field(description="生成したファイルのリスト(filename, content)")
    setup_instructions: str = Field(description="セットアップ手順")

class CodingAgent:
    def __init__(self, model_name: str = "gpt-oss:20b"):
        self.llm = Ollama(model=model_name, temperature=0.15)
        self.prompt = ChatPromptTemplate.from_messages([
            ("system", """あなたはシニアのバックエンドエンジニアです。
設計書に基づいてPythonコードを生成してください。
- FastAPIを使用
- 型ヒントを必ず付ける
- docstringは英語で記述
- エラーハンドリングを適切に実装"""),
            ("human", """以下のAPIエンドポイントを実装してください:
{endpoint}

DBスキーマ: {db_schema}
技術スタック: {tech_stack}""")
        ])

    def run(self, design_doc: DesignDoc) -> CodeDoc:
        all_files = []
        # エンドポイントごとに分割生成
        for endpoint in design_doc.api_endpoints:
            chain = self.prompt | self.llm
            code = chain.invoke({
                "endpoint": str(endpoint),
                "db_schema": str(design_doc.db_schema),
                "tech_stack": ", ".join(design_doc.tech_stack)
            })
            all_files.append({
                "filename": f"api_{endpoint.get('path','').strip('/').replace('/','_')}.py",
                "content": code
            })
        return CodeDoc(
            files=all_files,
            setup_instructions=f"Tech stack: {', '.join(design_doc.tech_stack)}"
        )

テストエージェント:コードからテストを生成する

テストエージェントは生成されたコードファイルを受け取り、pytestベースのテストコードを生成します。ここでもファイルごとに分割呼び出しです。一度に全コードを渡すとテストの質が落ちる。

class TestDoc(BaseModel):
    test_files: List[dict] = Field(description="テストファイルのリスト(filename, content)")
    coverage_notes: List[str] = Field(description="カバレッジ上の注意点・未テスト箇所")

class TestAgent:
    def __init__(self, model_name: str = "gpt-oss:20b"):
        self.llm = Ollama(model=model_name, temperature=0.1)
        self.prompt = ChatPromptTemplate.from_messages([
            ("system", """あなたはQAエンジニアです。pytestを使ったテストコードを生成してください。
- 正常系・異常系・境界値を網羅
- モックは unittest.mock を使用
- テスト関数名は test_[動詞]_[対象]_[条件] の形式で"""),
            ("human", "以下のコードのテストを生成してください:\n\n{source_code}")
        ])

    def run(self, code_doc: CodeDoc) -> TestDoc:
        test_files = []
        for file in code_doc.files:
            chain = self.prompt | self.llm
            test_code = chain.invoke({"source_code": file["content"]})
            test_files.append({
                "filename": f"test_{file['filename']}",
                "content": test_code
            })
        return TestDoc(
            test_files=test_files,
            coverage_notes=["境界値テストは手動での確認を推奨"]
        )

オーケストレーション:4エージェントをパイプラインで繋ぐ

最後に、4つのエージェントを順番に実行するオーケストレーターを実装します。各フェーズの結果をログに残しておくと、どこで品質が落ちたか後から追跡できます。

import json
from datetime import datetime
from pathlib import Path

class DevPipeline:
    def __init__(self, model_name: str = "gpt-oss:20b", output_dir: str = "output"):
        self.req_agent = RequirementsAgent(model_name)
        self.design_agent = DesignAgent(model_name)
        self.coding_agent = CodingAgent(model_name)
        self.test_agent = TestAgent(model_name)
        self.output_dir = Path(output_dir)
        self.output_dir.mkdir(exist_ok=True)

    def run(self, requirements_text: str) -> dict:
        timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
        results = {}

        print("▶ Phase 1: 要件定義エージェント")
        req_doc = self.req_agent.run(requirements_text)
        results["requirements"] = req_doc.model_dump()
        self._save(f"{timestamp}_requirements.json", results["requirements"])
        print(f"  曖昧な点: {len(req_doc.ambiguities)}件 / 確定仕様: {len(req_doc.confirmed_specs)}件")

        print("▶ Phase 2: 設計エージェント")
        design_doc = self.design_agent.run(req_doc)
        results["design"] = design_doc.model_dump()
        self._save(f"{timestamp}_design.json", results["design"])
        print(f"  APIエンドポイント: {len(design_doc.api_endpoints)}件")

        print("▶ Phase 3: 実装エージェント")
        code_doc = self.coding_agent.run(design_doc)
        results["code"] = code_doc.model_dump()
        self._save(f"{timestamp}_code.json", results["code"])
        print(f"  生成ファイル: {len(code_doc.files)}件")

        print("▶ Phase 4: テストエージェント")
        test_doc = self.test_agent.run(code_doc)
        results["tests"] = test_doc.model_dump()
        self._save(f"{timestamp}_tests.json", results["tests"])
        print(f"  テストファイル: {len(test_doc.test_files)}件")

        return results

    def _save(self, filename: str, data: dict):
        with open(self.output_dir / filename, "w", encoding="utf-8") as f:
            json.dump(data, f, ensure_ascii=False, indent=2)

# 実行例
if __name__ == "__main__":
    pipeline = DevPipeline(model_name="gpt-oss:20b")
    requirements = """
    ユーザー管理APIを作りたい。
    ユーザーの登録・ログイン・プロフィール更新ができること。
    認証はJWTを使う。DBはPostgreSQLを想定。
    """
    results = pipeline.run(requirements)
運用Tips

各フェーズの出力をJSONファイルとして保存しておくと、途中のフェーズからやり直せます。要件定義だけ人間がレビューして修正し、設計以降を再実行する、という使い方が現実的です。

実運用での限界と人間の介在ポイント

このパイプラインを実際に使ってみて気づいた限界をいくつか挙げておきます。まず、要件が曖昧なまま進むと雪だるま式に品質が落ちる。RequirementsAgentが出した曖昧さリストを無視してDesignAgentに進むと、設計の前提が崩れ、コードもテストも連鎖的に歪みます。

もうひとつは、テストエージェントのエッジケース認識が甘いこと。正常系は網羅してくれますが、「このAPIに不正なJWTを渡したらどうなるか」といった攻撃的なテストケースは自分で足す必要があります。コストの話をすると、ローカルLLMなのでAPI費用はゼロですが、20Bモデルで全フェーズ回すと5〜10分かかります。小規模プロジェクトなら十分実用的な速度です。

人間が介在すべきポイントは明確で、Phase 1終了後の曖昧さレビューPhase 3終了後のコードレビューの2点。それ以外はエージェントに任せて、人間は判断に集中する——これがこのアーキテクチャの狙いです。

Google Antigravityで変わるAI駆動開発:フェーズ別エージェント分業の実践

Google Antigravityで変わるAI駆動開発:フェーズ別エージェント分業の実践

先月、お客さんから「AI使えばもう設計書いらないですよね?」と言われまして。思わず苦笑いしてしまいました。確かに、Copilotやら何やらで「コードを書く速度」は上がった。でも要件定義でAIに曖昧な指示を投げると、自信満々で的外れなものを返してくる。「1つのAIに全部やらせる」という発想は、もう少し慎重に考えたほうがいいんじゃないかと思っていたんですよね。そこに出てきたのが、GoogleのAntigravityです。

注目ポイント

Antigravityの本質は「コード補完の強化」ではなく、「フェーズごとに専門エージェントを分業させ、人間はレビューに集中する」という設計思想の転換にある。

なぜ「1つのAI」では限界が来るのか

CursorやGitHub Copilotを使っている方なら実感があると思いますが、あのツールは基本的に「今書いているコードの文脈」しか見ていません。要件定義の話をしながら同時に実装コードを提案させると、途端にコンテキストが混乱する。結果、中途半端な出力になる。

これは設計の問題でもあって、要件定義・設計・実装・テストはそれぞれ「考え方の粒度」が全然違います。要件定義は「何を作るか」の議論、設計は「どう作るか」の整理、実装は「書く」作業、テストは「壊す」作業。これを1つのLLMに同時にやらせようとするから歪みが出る。Antigravityはここに目を向けた、という点で面白い。

Google Antigravityとは何者か

2025年11月にGoogleが発表したエージェント・ファーストのIDEです。VS Codeフォークなので、今使っている拡張機能や設定はそのまま使えます。この点はチームへの展開コストが低くて助かりますね。

特徴的な機能は3つです。エージェント・マネージャーでバックグラウンドの複数エージェントを並行稼働させられること、ブラウザ・エージェントがAI自身でドキュメントを調査してスクリーンショットまで撮れること、そしてArtifactsでAIの処理結果をタスクリスト・プラン・動画として可視化できること。この3つが噛み合うと、開発フローが変わります。

要件定義フェーズ:曖昧さを炙り出すエージェント

要件定義で一番つらいのは「曖昧なまま進んでしまうこと」です。お客さんの言う「使いやすいUI」って何なのか、「リアルタイム」って何ミリ秒を指しているのか。ここを詰め切れないまま設計に入ると、後で痛い目を見ます。

Antigravityでは、要件ヒアリングのメモや議事録を投げると、エージェントが「この要件は定義が曖昧です。以下を確認してください」という質問リストをArtifactsとして出力します。人間がやると遠慮が入るこの「ツッコミ」を、AIに任せるのは案外合理的です。

注意

エージェントが出した質問リストをそのままお客さんに送るのは危険です。技術的すぎる、あるいは失礼な表現が混じることがある。あくまで「人間がレビューする素材」として使うのが正解です。

設計フェーズ:Artifactsで叩き台を作らせる

設計フェーズでのAntigravityの使い方は「叩き台の高速生成」です。確定した要件をまとめたドキュメントを渡すと、エージェントがアーキテクチャ案・テーブル設計・APIエンドポイント一覧をArtifactsとして出力します。

これが地味に効いてくる。設計レビューって、ゼロから書いたものを見るより「これでいいか?」と叩き台を渡された方が指摘しやすいんですよね。エンジニア全員が設計を書ける訳じゃないし、特にジュニアメンバーは「何から書けばいいかわからない」という状態になりやすい。Artifactsが最初のたたき台を作ってくれるだけで、議論の密度が上がります。

実装フェーズ:ブラウザ・エージェントに調査を丸投げする

実装中に一番時間を取られるのって、コードを書くことより「ドキュメントを読む時間」じゃないかと思っています。新しいライブラリを使うとき、公式ドキュメントを読んで、Stack Overflowを漁って、GitHubのIssueを確認して…。

Antigravityのブラウザ・エージェントは、AIが自分でブラウザを操作してドキュメントを調査し、「このライブラリでやりたいことを実現するコード例」を持ってきます。自分が読む必要がなくなる、とは言いませんが、調査の起点として使うと明らかに速い。うちのチームでは「まずAntigravityに調べさせて、人間が裏取りする」という流れに変わりつつあります。

テストフェーズ:バックグラウンドで回し続ける

テストエージェントをバックグラウンドで動かしながら実装を続ける、というのがAntigravityの真骨頂です。実装中にエージェントが並行して「このコードに対するテストケース案」を生成し続けてくれる。

正直、テストを書く習慣がないチームには少し敷居が高いですが、「テストの素材をAIに作らせて、人間が選ぶ」というプロセスなら受け入れやすい。全部信用するのは危ないですが(エッジケースの認識が甘いことがある)、カバレッジの穴を埋める用途には十分使えます。

実践メモ

バックグラウンドエージェントはリソースを食います。ローカルマシンのスペックが低いと逆に開発体験が悪化します。チーム導入前にスペック要件を確認しておくのが無難です。

人間がやるべき仕事は何か

ここまで書いてきて思うのは、Antigravityを使いこなすには「何をエージェントに任せ、何を自分で判断するか」のタスク設計センスが問われるということです。ツールが変わっても、要件の本質を掴む力や、設計の良し悪しを判断する経験値は、引き続き人間の仕事です。

コストの話をすると、現時点でAntigravityのエンタープライズプランは月額が安くない。ただ、要件定義のやり直しが1回減るだけで、十分に元が取れる規模感の案件が多いのも事実です。まずは小規模プロジェクトで試して、上司への稟議のネタを作るところから始めるのが現実的かなと思っています。

2026/03/04

Androidで縦横斜めを自由スクロール!KotlinでカスタムViewGroup「VHScrollView」を実装する

Androidで縦横斜めを自由スクロール!KotlinでカスタムViewGroup「VHScrollView」を実装する

はじめに

Androidアプリを開発していると、「縦方向だけでなく横方向にも、しかも斜め方向にも自由にスクロールできるViewが欲しい」という場面に出くわすことがあります。地図や大きなスプレッドシート、画像ビューアなどがその典型です。標準の ScrollView は縦方向のみ、HorizontalScrollView は横方向のみと、それぞれ一方向にしか対応しておらず、組み合わせ次第では相互のタッチイベントが干渉しあい、思うような動作が得られないことも少なくありません。

本記事では、Kotlinで FrameLayout を継承して構築した VHScrollView(Vertical-Horizontal ScrollView)クラスの設計思想と実装の全コードを解説します。GestureDetectorCompatOverScroller を組み合わせたAndroid標準コンポーネント活用の実践的な例として、カスタムViewのアーキテクチャを理解したい方にも最適な内容です。

基礎知識・概要

Key Concept

GestureDetectorCompat にジェスチャー解析を委譲しつつ、OverScroller で慣性スクロールの物理計算をOSに任せる「責務の分離」設計が、少ないコード量でSwipe/Fling両対応を可能にしています。

Androidのカスタムスクロールビューを実装する際に欠かせない2つのクラスを整理します。

GestureDetectorCompat: MotionEventの生ストリームを受け取り、「タッチダウン」「ドラッグ(onScroll)」「フリック(onFling)」などの高レベルなジェスチャーイベントに変換してくれるユーティリティクラスです。自力でタッチ座標の差分を計算したり、感度を実装する必要がなく、Androidの標準的な判定ルールを再利用できます。

OverScroller: フリング(弾き飛ばし)時の速度減衰・慣性アニメーションの座標計算を担当するクラスです。毎フレームの描画タイミングで computeScrollOffset() を呼ぶことで現在の理想スクロール位置を取得でき、端末のリフレッシュレートに合わせた滑らかな慣性アニメーションを、OSが計算してくれます。このふたつを組み合わせることで、スクロールロジックの本質(どこまでスクロールするか・何が端か)だけを書けばよくなります。

主要機能と詳細

2つのGestureDetectorの役割分担

VHScrollView の設計上の面白い点は、GestureDetectorCompat を用途別に2つ保持していることです。

  • interceptDetector: onInterceptTouchEvent 専用。子Viewにイベントが届く前に「これはスクロール動作か?」を検知し、isScrolling フラグを立てるためだけに使われます。
  • gestureDetector: onTouchEvent 専用。インターセプト後に配送されるイベントを受け取り、実際のスクロール移動(onScroll)およびフリング開始(onFling)処理を行います。

この分離により、子Viewが独自のタッチ処理(クリック等)を持っていても、サコンフリクトを最小限に抑えた自然なUXを保てます。

onMeasureとUNSPECIFIEDの意味

スクロールビューの根幹となる重要な処理が onMeasure 内の子ビューへの MeasureSpec.UNSPECIFIED 指定です。通常、親Viewは子Viewに「最大でこのサイズまでの表示を許可する」という制約(MeasureSpec)を渡します。しかしスクロールビューがそれをやってしまうと、子ビューが画面サイズに収まるよう自ら縮小してしまい、スクロールする意味がなくなります。UNSPECIFIED(制約なし)を渡すことで、「好きなサイズになっていい」と子ビューに伝え、その結果えられた子ビューの measuredWidth/Height と自身の表示領域との差が、スクロール可能な最大移動量(maxX / maxY)になります。

doScrollByとdoFlingの役割

doScrollBy はドラッグ中の指の移動量(distanceX/Y)をそのままスクロール位置に反映する最もシンプルな関数です。ここで coerceIn(0, maxX) によるクランプ処理(範囲固定)を行い、子Viewの端を超えてスクロールされないようにしています。

一方 doFling では、指を弾いた瞬間の速度(velocityX/Y)を OverScroller.fling() に渡し、以後の座標計算をOSに委ねます。GestureDetectorの返す速度は「指の移動方向」なので、スクロール(コンテンツの移動方向は逆)に合わせてマイナスに反転しているのがポイントです。

実装・実践ガイド:コードの詳細と使い方

computeScrollによるアニメーションループ

Androidのレンダリングループと OverScroller を繋ぐ「のり」が computeScroll() のオーバーライドです。フレームごとのVSYNC信号に合わせて呼ばれるこのメソッドで、scroller.computeScrollOffset() を呼ぶと OverScroller が減速計算を行い、現在フレームでの理想座標(currX/Y)を返してくれます。それを scrollTo() で適用し、最後に ViewCompat.postInvalidateOnAnimation(this) で次フレームの描画を再予約する、という無限ループでアニメーションが継続します。アニメーション終了時は computeScrollOffset()false を返すためループが自然に終了します。

XMLレイアウトへの組み込み方法

使い方はシンプルです。スクロールさせたい大きなビューを、VHScrollView の直下の子(1つだけ)として配置するだけです。

<com.example.vhscrollview.VHScrollView
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <!-- スクロールさせたい巨大なコンテンツView -->
    <ImageView
        android:layout_width="3000dp"
        android:layout_height="2000dp"
        android:src="@drawable/big_map" />

</com.example.vhscrollview.VHScrollView>

これだけで、ユーザーが指を動かした方向(縦・横・斜め)に合わせた自然なスクロールと、指を弾いた際のフリング慣性アニメーションが動作します。

依存関係の追加(build.gradle)

本実装は AndroidX Core の ViewCompatGestureDetectorCompat を利用します。build.gradle(またはbuild.gradle.kts)の dependencies ブロックに以下が含まれていることを確認してください。

dependencies {
    implementation("androidx.core:core-ktx:1.12.0")
}

よくある課題と解決策

注意点

子Viewが RecyclerView など独自スクロールを持つ場合、タッチイベントの競合に注意が必要です。

子ViewにクリックやRecyclerViewが共存する場合

onInterceptTouchEvent でスクロール意図を検知した後にインターセプトする設計により、短いタップは子Viewに届きます。ただし、子View自体がスクロール可能な場合(RecyclerView など)は、ネストスクロールの競合が発生します。その場合は NestedScrollingParent3 インターフェースを追加実装し、requestDisallowInterceptTouchEvent の仕組みを組み合わせた制御が必要です。

端の「バウンス」エフェクトを追加する

現状の実装はコンテンツ端でピタッと止まる設計です(クランプ処理)。iOS風の「端を超えて少し伸びて戻る」バウンスエフェクトを追加したい場合は、OverScroller.fling() に オーバースクロールの許容量を渡す overX/overY パラメーターを設定し、EdgeEffect クラスを組み合わせることで実現できます。

アクセシビリティ(a11y)への対応

カスタムスクロールViewはスクリーンリーダー(TalkBack)からのスクロール操作が考慮されていません。ViewCompat.setAccessibilityDelegate を使ってスワイプアクションを定義するか、onInitializeAccessibilityNodeInfo をオーバーライドしてスクロール可能であることをアクセシビリティツリーに通知することが求められます。

まとめ

本記事では、FrameLayout を継承したカスタムViewGroup「VHScrollView」のKotlin実装を解説しました。設計のポイントを振り返ります。

  • インターセプト用と操作用で GestureDetectorを責務分離 し、子Viewとのタッチ競合を最小化。
  • MeasureSpec.UNSPECIFIED で子Viewを 「好きなサイズ」で計測 し、スクロール可能領域を正しく算出。
  • OverScroller に物理演算を委譲し、computeScroll() ループで OSネイティブ品質の慣性スクロール を実現。

この設計パターンは縦横スクロールに限らず、カスタムジェスチャー操作全般に応用が利きます。地図ビューアや大型レイアウトの閲覧UI、図面エディタのベースコンポーネントとしてぜひ活用してみてください。

完全なソースコード(VHScrollView.kt)

以下に VHScrollView.kt の完全なソースコードを掲載します。パッケージ名は各自のプロジェクトに合わせて変更してください。

package com.example.vhscrollview

import android.content.Context
import android.util.AttributeSet
import android.view.GestureDetector
import android.view.MotionEvent
import android.widget.FrameLayout
import android.widget.OverScroller
import androidx.core.view.GestureDetectorCompat
import androidx.core.view.ViewCompat

/**
 * 縦・横・斜めに自由にスクロールできるカスタム ViewGroup。
 *
 * 設計方針:
 * - [FrameLayout] を継承し、直下の子ビューを1つだけ持つ([android.widget.ScrollView] と同じ制約)。
 * - [GestureDetectorCompat] に `MotionEvent` の解析を委譲し、
 *   `onScroll`(ドラッグ移動量)と `onFling`(弾き初速)コールバックだけを処理する。
 * - [OverScroller] に X/Y の速度と限界値を渡し、OS 標準の慣性スクロール計算を利用する。
 */
class VHScrollView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : FrameLayout(context, attrs, defStyleAttr) {

    private val scroller = OverScroller(context)

    /**
     * onInterceptTouchEvent でドラッグを検知するための専用 GestureDetector。
     * onScroll が呼ばれた = スクロール意図あり → インターセプトフラグを立てる。
     */
    private var isScrolling = false
    private val interceptDetector = GestureDetectorCompat(
        context,
        object : GestureDetector.SimpleOnGestureListener() {
            override fun onDown(e: MotionEvent): Boolean = true
            override fun onScroll(
                e1: MotionEvent?, e2: MotionEvent, distanceX: Float, distanceY: Float
            ): Boolean {
                isScrolling = true
                return true
            }
        }
    )

    private val gestureDetector = GestureDetectorCompat(
        context,
        object : GestureDetector.SimpleOnGestureListener() {

            /**
             * タッチダウン時にフリングアニメーションを止める。
             * `onScroll` / `onFling` を受け取るには true を返す必要がある。
             */
            override fun onDown(e: MotionEvent): Boolean {
                if (!scroller.isFinished) {
                    scroller.abortAnimation()
                }
                return true
            }

            /**
             * ドラッグ中に呼ばれる。指の移動量(distanceX, distanceY)をそのままスクロールに反映する。
             */
            override fun onScroll(
                e1: MotionEvent?,
                e2: MotionEvent,
                distanceX: Float,
                distanceY: Float
            ): Boolean {
                doScrollBy(distanceX.toInt(), distanceY.toInt())
                return true
            }

            /**
             * 指を弾いた時に呼ばれる。フリングの初速を [OverScroller] に渡し、慣性計算を開始する。
             * GestureDetector が返す velocityX/Y は「指の速度」なので、スクロール方向は反転する。
             */
            override fun onFling(
                e1: MotionEvent?,
                e2: MotionEvent,
                velocityX: Float,
                velocityY: Float
            ): Boolean {
                doFling(-velocityX.toInt(), -velocityY.toInt())
                return true
            }
        }
    )

    // -------------------------------------------------------------------------
    // Measure
    // -------------------------------------------------------------------------

    /**
     * 子ビューを [MeasureSpec.UNSPECIFIED] で計測する。
     * これにより、親の画面サイズを超えた大きな子ビューも本来のサイズで計測される。
     */
    override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {
        super.onMeasure(widthMeasureSpec, heightMeasureSpec)
        if (childCount == 0) return

        val child = getChildAt(0)
        val unspecified = MeasureSpec.makeMeasureSpec(0, MeasureSpec.UNSPECIFIED)
        child.measure(unspecified, unspecified)
    }

    // -------------------------------------------------------------------------
    // Intercept
    // -------------------------------------------------------------------------

    /**
     * 子Viewよりも先にタッチイベントを確認し、ドラッグと判断したらインターセプト(横取り)する。
     * インターセプト後は以降のイベントが [onTouchEvent] に直接届くようになる。
     */
    override fun onInterceptTouchEvent(ev: MotionEvent): Boolean {
        // ACTION_CANCEL / ACTION_UP でフラグをリセット
        if (ev.action == MotionEvent.ACTION_CANCEL || ev.action == MotionEvent.ACTION_UP) {
            isScrolling = false
        }
        interceptDetector.onTouchEvent(ev)
        return isScrolling
    }

    // -------------------------------------------------------------------------
    // Touch
    // -------------------------------------------------------------------------

    override fun onTouchEvent(event: MotionEvent): Boolean {
        return gestureDetector.onTouchEvent(event) || super.onTouchEvent(event)
    }

    // -------------------------------------------------------------------------
    // Scroll
    // -------------------------------------------------------------------------

    /**
     * 現在位置に [dx], [dy] を加算してスクロール位置を更新する。
     * 0 〜 maxScroll の範囲にクランプすることで画面端を超えないようにする。
     */
    private fun doScrollBy(dx: Int, dy: Int) {
        val child = getChildAt(0) ?: return
        val maxX = (child.measuredWidth - width).coerceAtLeast(0)
        val maxY = (child.measuredHeight - height).coerceAtLeast(0)
        scrollTo(
            (scrollX + dx).coerceIn(0, maxX),
            (scrollY + dy).coerceIn(0, maxY)
        )
    }

    /**
     * [OverScroller.fling] に X/Y の初速と限界値を設定し、慣性スクロールを開始する。
     * 実際の座標反映は [computeScroll] で毎フレーム行う。
     */
    private fun doFling(velocityX: Int, velocityY: Int) {
        val child = getChildAt(0) ?: return
        val maxX = (child.measuredWidth - width).coerceAtLeast(0)
        val maxY = (child.measuredHeight - height).coerceAtLeast(0)

        scroller.fling(
            scrollX, scrollY,
            velocityX, velocityY,
            0, maxX,
            0, maxY
        )
        ViewCompat.postInvalidateOnAnimation(this)
    }

    // -------------------------------------------------------------------------
    // Animation loop
    // -------------------------------------------------------------------------

    /**
     * [ViewCompat.postInvalidateOnAnimation] によるフレームごとに呼ばれる。
     * [OverScroller] が計算した現在座標を取り出し、[scrollTo] で位置を確定する。
     * アニメーションが続く間は次フレームの描画を再予約する。
     */
    override fun computeScroll() {
        super.computeScroll()
        if (!scroller.computeScrollOffset()) return

        val child = getChildAt(0)
        val maxX = child?.let { (it.measuredWidth - width).coerceAtLeast(0) } ?: 0
        val maxY = child?.let { (it.measuredHeight - height).coerceAtLeast(0) } ?: 0

        scrollTo(
            scroller.currX.coerceIn(0, maxX),
            scroller.currY.coerceIn(0, maxY)
        )
        ViewCompat.postInvalidateOnAnimation(this)
    }
}