3つの独立したGoogle Apps Scriptプロジェクトを、統合された2ファイル構造にリファクタリングした。これにより、メンテナンスが容易になり、機能の重複も解消された。 元の構造： 各スクリプトは独立して動作していたが、共通のコード（GitHub API呼び出し、認証処理など）が重複していた。 新しい構造： Code.gs（メインファイル） ProfWorkflows.gs（専門ワークフロー） この構造は、「Taavi-B Gateway」Webアプリアーキテクチャをベースにしている。すべてのAPI操作は、統一されたエントリーポイント（doGet()）を通過する。 統合のメリット： デプロイ後の設定： 現在、統合スクリプトは安定稼働している。3つの独立したプロジェクトの機能がすべて利用可能で、コードベースは半分以下に削減された。

辞書プロジェクトで、AIが自動的にGitHubにコミットする際、誰がコミットしたのか分かりにくいという問題があった。すべてのコミットが私のアカウントで実行されるため、GitHubのコントリビューショングラフでAIの作業が見えなかった。 解決策は、専用のBotアカウント（mn-dict-bot）を作成することだった。このアカウント用のPersonal Access Token（PAT）を発行し、Google Apps Scriptから使用する。これにより、Botによるコミットが私のコミットと明確に区別される。 実装は意外と簡単だった。GitHubで新しいアカウントを作成し、Settings > Developer settings > Personal access tokensからトークンを生成する。必要なスコープはrepo（リポジトリへの完全アクセス）だ。 このトークンをGoogle Apps ScriptのScript Propertiesに保存し、GitHub APIを呼び出す際に使用する。具体的には、HTTPリクエストのAuthorizationヘッダーにtoken <PAT>を含める。 興味深い発見は、コミット者とオーサーの違いだった。GitHubのコミットには、committer（実際にコミットを実行した人）とauthor（変更を作成した人）の2つの情報がある。Botアカウントを使う場合、両方ともBotに設定するのが適切だ。 現在、mn-dict-botは安定稼働している。GitHubのコントリビューショングラフを見ると、Botアカウントのアバター（小さなロボットのアイコン）がコミット履歴に表示され、自動化された作業が一目で分かる。これにより、プロジェクトの透明性が向上した。

GitHub操作スクリプトで、Issue一覧の表示方法を改善した。当初、すべてのIssueデータをコマンドシートの結果カラムに出力していたが、これがスプレッドシートを混雑させていた。 改善前の動作： これでは、他のコマンドの結果が見づらくなる。 改善後の動作： 実際のIssueデータは、専用のIssue_Indexシートに書き込まれる： Issue # Title State Created Author 123 Bug in parser open 2025-09-14 itako999 124 Feature request open 2025-09-13 mn-dict-bot 実装の鍵： 同様の改善をfile読み取りにも適用： ファイルの内容を結果カラムに出力する代わりに、新しいGoogle Docに保存し、そのURLを返す： テキストフォーマットのバグ修正： 当初、改行が正しく処理されず、すべてのテキストが1行に表示されていた。複数の改行タイプ（\n, \r, \r\n）に対応する堅牢な正規表現を実装した： 現在、GitHubスクリプトはクリーンなコントロールパネルとして機能している。複雑な操作は実行するが、ユーザーインターフェース（コマンドシート）は整理されたまま保たれる。

複数のAIペルソナが協働するプロジェクトでは、情報共有の仕組みが重要だ。当初、各AIがGoogle DriveやGitHubリポジトリのファイルに直接書き込む方式を検討したが、これには複雑なアクセス制御と競合解決が必要だった。 そこで発想を転換し、GitHub Issuesを「掲示板」として使うアーキテクチャに変更した。各AIは、作業結果や質問をIssueとして投稿する。他のAIや人間はそれを読み、コメントで応答する。この方式なら、複雑なファイル書き込み制御が不要になる。 実装にあたっては、Google Apps ScriptでGitHub APIを呼び出すインターフェースを開発した。Google Sheetからコマンドを入力すると、自動的にIssueが作成され、結果がシートに返される仕組みだ。 興味深い改善点は、結果の返し方だった。当初、APIの応答内容をすべてGoogle Docに保存し、そのURLを返していた。しかし、単純な操作（Issueの作成など）では、これは過剰だった。そこで、簡単な操作ではSHA値や確認メッセージを直接Spreadsheetのセルに書き込み、複雑な操作（ファイルの読み取りなど）だけGoogle Docに保存する方式に変更した。 また、Issue一覧の取得も工夫した。すべてのIssueをSpreadsheetに出力すると、セルが大量のデータで埋まってしまう。そこで、専用のIssue_Indexシートを作成し、そこに一覧を出力するようにした。コマンドシート自体は確認メッセージだけを返すため、すっきりした。 現在、このシステムは安定稼働している。AIペルソナたちはGitHub Issuesを通じてスムーズにコミュニケーションしており、人間もその会話をWebブラウザから簡単に追跡できる。分散型コラボレーションの一つのモデルになったと思う。

ChatGPTのカスタムアクション機能を使って、Taavi（ChatGPT）がGitHub APIに直接アクセスできるようにするスキーマを開発した。これにより、会話の中でGistやIssueを作成・管理できるようになる。 最大の課題は、Personal Access Token（PAT）のスコープ制限だった。最初、基本的なgistスコープだけでGistとIssueの両方を操作できると思い込んでいた。しかし、実際にはIssueを操作するにはrepoスコープが必要だった。 さらに、OpenAIのActionコネクターには独自の制約があることもわかった。すべてのGitHub API操作がサポートされているわけではなく、特定のエンドポイントしか使えない。これはセキュリティ上の理由だと思われるが、ドキュメントには明記されていない。 もう一つの発見は、ステートベースのフィルタリングの必要性だった。Issueを取得する際、デフォルトではopenとclosedの両方が返される。しかし、ほとんどの場合、openなIssueだけを見たい。スキーマにstate=openパラメータを明示的に指定することで、この問題を解決した。 最終的に、Gist（作成、コメント、一覧取得）とIssue（作成、コメント、一覧取得）の両方に対応したマルチエンドポイントスキーマが完成した。これにより、Taaviは会話の中で自然にGitHub操作を実行できるようになった。 次のステップは、Taavi-B Gatewayアクションスキーマの開発だ。これは、高権限操作（リポジトリファイルの書き込みなど）のために、Admin PATを使用するGoogle Apps Script経由でアクセスする。直接アクセスとGateway経由のアクセスを組み合わせることで、セキュリティを保ちながら柔軟な操作を実現する。

辞書データの高度な検証作業をClaudeに依頼するため、「S07 Gist検証ブリッジ」というGoogle Apps Scriptツールを開発した。Google SheetsのデータをGitHub Gistにエクスポートし、Claudeが検証結果を別のGistに書き込み、それを再びGoogle Sheetsにインポートする仕組みだ。 最大の技術的課題は、セキュリティとアクセス制御だった。2つのPersonal Access Token（PAT）を使う方式を採用した。ユーザーのPATでユーザー所有のGistにエクスポートし、BotのPATでBot所有のGistから結果をインポートする。この分離により、ClaudeはユーザーのGoogle Sheetsに直接アクセスすることなく、検証作業を実行できる。 実装過程で、いくつかのバグに遭遇した。最も厄介だったのは、JSON変換ロジックの誤りだった。Google SheetsのデータをJSON形式に変換する際、セルの値の型（文字列、数値、空白）を正しく扱わないと、エクスポートされたデータが壊れてしまう。 もう一つの問題は、範囲の扱いだった。ヘッダー行を含めるか含めないか、空白行をどう処理するかなど、細かい仕様の決定が必要だった。最終的には、明示的にヘッダー行をスキップし、空白行を除外する処理を実装した。 ブラウザキャッシュの問題にも悩まされた。スクリプトを修正してデプロイしても、ブラウザが古いバージョンのHTMLやJavaScriptをキャッシュしていて、変更が反映されないことがあった。強制リロード（Ctrl+Shift+R）が必要だと学んだ。 現在、S07ツールは安定稼働している。ワークフローは次の通りだ：Google Sheetsの_Stagingタブからデータをエクスポート→ClaudeがGist経由でデータを受け取り検証→Claudeが結果を新しいGistに書き込み→S07ツールが結果をインポートして指定タブに書き込む。この自動化により、検証作業の効率が大幅に向上した。

辞書データの品質管理のため、3つの独立したGoogle Apps Scriptツール（Pivot Report、File List Checker、Delta Tracker）を統合し、新しい「S06データ監査ツール」プロジェクトを作成した。 統合の目的は、作業効率の向上だった。以前は、ピボットレポートを生成したい時、ファイルリストをチェックしたい時、差分を追跡したい時に、それぞれ別のスプレッドシートを開いて別のスクリプトを実行する必要があった。これを単一のサイドバーUIから呼び出せるようにした。 技術的に興味深かったのは、HTMLボタンのtype属性の扱いだった。最初の実装では、すべてのボタンにtype=”submit”を指定していた。これがフォーム内で予期しない動作を引き起こし、意図しない関数が実行されてしまった。解決策は、明示的にtype=”button”を指定することだった。 もう一つの課題は、設定の保存処理だった。Delta Trackerで使用するスナップショットのプレフィックスを保存する際、変数のスコープの問題でundefinedが保存されてしまった。これはJavaScriptの基本的な問題だが、デバッグには時間がかかった。 現在、S06ツールは3つの機能を統合したサイドバーから利用できる。Pivot Reportはフォルダ内のエントリ数をステータスとサブフォルダで集計し、File List Checkerは特定のファイル群の存在を確認し、Delta Trackerは2つのスナップショット間の差分を追跡する。 これらのツールは、S04（データ処理ツール）とは論理的に分離されている。S04は「データを変換する」ツールであり、S06は「データを検証する」ツールだ。この分離により、それぞれの役割が明確になり、メンテナンスも容易になった。

辞書データの品質管理で重要なのが、各エントリの分類（CAT）の妥当性確認だ。これを自動化するため、Gemini APIを活用したCATチェッカーをGoogle Apps Scriptで実装した。 当初、Gemini APIに詳細な説明文を返させる設計だった。「この単語は名詞です。なぜなら…」という形式だ。しかし、これには2つの問題があった。第一に、出力が冗長で人間のレビュアーが読むのが大変だった。第二に、APIのトークン消費量が多く、コストが高かった。 そこで、プロンプトを最適化し、簡潔な絵文字インジケーター（✅）を返すように変更した。CATが正しければ✅、疑わしければ空白。これだけでレビュアーは一目で判断できる。トークン消費量も大幅に削減された。 もう一つの重要な改良は、非破壊的なワークフローの実装だった。元のデータを直接変更するのではなく、「Staging」タブを作成し、そこで検証作業を行う。元の「Source」データは常に無傷のまま保持される。これにより、何か問題が起きても、簡単に元の状態に戻せる。 API呼び出しのエンドポイントでも失敗した。最初、標準的なGemini APIのURLを使っていたが、404エラーが返ってきた。ユーザーから指摘を受けて、gemini-2.5-flash-liteという特定のモデル名を使う必要があることがわかった。APIのバージョンやモデル名の指定は、ドキュメントをよく読まないとわからないことが多い。 現在、CATチェッカーは安定稼働している。数千件のエントリを自動的にチェックし、疑わしいものにフラグを立てる。最終的な判断は人間が行うが、AIが事前にフィルタリングしてくれることで、作業効率が劇的に向上した。

ᠶᠠᠫᠣᠨ ᠦ ᠭᠦᠨᠮᠠ ᠮᠣᠵᠢ ᠳ᠋ᠣ ᠣᠷᠣᠰᠢᠳᠠᠭ ᠬᠠᠭᠣᠴᠢᠨ ᠲᠣᠮᠢᠣᠺᠠ ᠢᠢᠨ ᠲᠣᠷᠭ᠎ᠠ ᠢᠢᠨ ᠦᠢᠯᠡᠳᠪᠦᠷᠢ ᠢᠢᠨ ᠴᠣᠭᠴᠠᠯᠠᠪᠣᠯᠢ ᠶᠢ ᠳᠡᠯᠡᠬᠡᠢ ᠢᠢᠨ ᠰᠣᠶᠣᠯ ᠦᠨ ᠦᠪ ᠢᠶᠡᠷ ᠪᠦᠷᠢᠳᠭᠡᠭᠦᠯᠬᠦ ᠨᠢ ᠵᠦᠢ ᠲᠡᠢ ᠭᠡᠵᠦ ᠦᠵᠡᠭᠰᠡᠨ ᠢᠶᠡᠨ UNESCO ᠢᠢᠨ ᠵᠦᠪᠯᠬᠦ ᠪᠠᠢᠢᠭᠣᠯᠣᠯᠭ᠎ᠠ ᠪᠣᠯᠬᠣ ICOMOS ᠮᠡᠳᠡᠭᠡᠯᠪᠡ᠃ ᠲᠣᠰ ᠦᠢᠯᠳᠪᠦᠷᠢ 140 ᠵᠢᠯ ᠦᠨ ᠡᠮᠣᠨ᠎ᠡ ᠪᠠᠢᠢᠭᠣᠭᠣᠯᠠᠭᠳᠠᠭᠰᠠ ᠶᠠᠫᠨ ᠳ᠋ᠣ ᠠᠩᠬᠠ ᠦ ᠲᠦᠷᠦ ᠢᠢᠨ ᠦᠮᠴᠢ ᠢᠢᠨ ᠲᠥᠷᠭ᠎ᠠ ᠢᠢᠨ ᠲᠡᠭᠦᠬᠡᠢ ᠡᠳ᠋ ᠪᠡᠯᠡᠳᠭᠡᠳᠡᠭ ᠦᠢᠯᠡᠳᠪᠦᠷᠢ ᠶᠣᠮ᠃ ᠲᠣᠬᠠᠢ ᠢᠢᠨ ᠦᠶ᠎ᠡ ᠢᠢᠨ ᠶᠠᠫᠣᠨ ᠦ ᠵᠠᠰᠠᠭ ᠦᠨ ᠭᠠᠵᠠᠷ ᠰᠢᠨ᠎ᠡ ᠲᠧᠺᠨᠣᠯᠣᠭᠢ᠎ ᠶᠢ ᠨᠡᠪᠲᠡᠷᠡᠬᠦᠯᠡᠨ ᠣᠷᠣᠭᠣᠯᠴᠣ ᠦᠢᠯᠡᠳᠪᠦᠷᠢᠵᠢᠭᠦᠯᠡᠬᠦ ᠪᠣᠳᠣᠯᠠᠭ᠎ᠠ ᠶᠠᠪᠣᠭᠣᠯᠣᠵᠣ ᠪᠠᠢᠪᠠ᠃ ᠶᠠᠫᠣᠨ ᠦ ᠨᠣᠳᠣᠭ ᠪᠦᠷᠢ […]

ᠰᠠᠢᠨ ᠪᠠᠢᠴᠭᠠᠭᠠᠨ᠎ᠠ ᠦᠦ᠃ ᠮᠠᠨ ᠦ ᠪᠣᠯᠦᠭ ᠳ᠋ᠣ ᠲᠠᠪᠠ ᠲᠠᠢ ᠮᠣᠷᠢᠯᠠᠨ᠋ᠠ ᠤᠤ! Google blogger ᠭᠡᠳᠡᠭ ᠪᠣᠯᠦᠭ᠎ ᠳᠡᠭᠡᠷ ᠡ ᠦᠭᠡᠷᠡᠴᠢᠯᠡᠯᠲᠡ ᠥᠷᠥᠭᠣᠯᠴᠣ ᠮᠣᠩᠭᠣᠯ ᠬᠡᠯᠡ ᠢᠶᠡᠷ ᠪᠣᠯᠦᠭ ᠬᠢᠵᠦ ᠦᠵᠬᠦ ᠭᠡᠵᠦ ᠪᠠᠢᠨ᠎ᠠ᠃ ᠠᠯᠮᠠᠰ ᠺᠣᠮᠫᠠᠨᠢ ᠢᠢᠨ ᠵᠣᠬᠢᠶᠠᠭᠰᠠᠨ ᠰᠺᠷᠢᠫᠲ ᠢ ᠠᠰᠢᠭᠯᠠᠪᠠ᠃ ᠲᠠ ᠪᠦᠬᠡᠨ ᠮᠢᠨᠦ ᠪᠢᠴᠢᠭᠰᠡᠨ ᠵᠣᠢᠯ ᠦᠨ ᠮᠣᠩᠭᠣᠯ ᠬᠡᠯᠡ ᠦ ᠠᠯᠳᠠᠭ᠎ᠠ ᠢ ᠵᠠᠰᠠᠵᠣ ᠦᠭᠬᠦᠨ᠎ᠡ᠎ ᠦᠦ᠃