伝統モンゴル文字ビューアの開発で、テキスト折り返し処理に長期間苦労していた。最終的に、CSS Columnsレイアウトモデルが最も安定した解決策だと判明した。 当初、Flexboxを試みた。親要素にdisplay: flexとflex-direction: columnを指定し、子要素を縦に並べる。しかし、長いテキストが画面外に突き抜けてしまい、折り返しを制御できなかった。 次に、white-space: nowrapとinline-blockの組み合わせを試した。これである程度機能したが、複数記事を表示する際、記事間の区切りが不明瞭になった。 CSS Columnsモデルの実装： この方法の鍵は、記事全体の高さを正確に計算することだった。行数、行の高さ、パディングを組み合わせて総高さを算出し、それをheightプロパティに設定する。 column-fill: autoにより、テキストは自動的に次のカラムに折り返される。overflow-x: autoにより、すべてのカラムが画面に収まらない場合、横スクロールが可能になる。 box-sizing: border-boxも重要だった。これにより、パディングとボーダーが指定されたheightに含まれる。デフォルトのcontent-boxでは、パディングが高さに追加され、計算が狂ってしまう。 現在のビューアはシンプル版で、最新の記事のみを表示する。完全版では記事リスト、追加・編集機能を統合する必要があるが、核心のテキスト表示ロジックは完成した。この安定したCSS基盤の上に、残りの機能を構築していく。

辞書プロジェクトのダッシュボード（v3.6）と、それが依存するS06ライブラリの統合作業で、一連の複雑なバグに遭遇した。 最初の問題は、関数の欠落だった。ダッシュボードのフロントエンドが呼び出している関数が、バックエンドのコードに存在しなかった。これは、コードの異なるバージョンが混在していたことが原因だった。バージョン管理の重要性を改めて認識させられた。 次に、関数呼び出しの名前の不一致があった。フロントエンドはfunctionA()を呼んでいるのに、バックエンドではfunctionB()という名前で定義されていた。JavaScriptは動的型付け言語なので、このような間違いがコンパイル時に検出されない。 さらに、OAuth権限スコープのエラーも発生した。Google Apps Scriptは、使用するGoogle APIに応じて適切な権限を要求する必要がある。権限が不足していると、実行時にエラーが発生する。appsscript.jsonのマニフェストファイルを正しく設定することが重要だ。 これらの問題を一つずつ解決していく過程で、「Staging Folder to Google Doc Logbook」ワークフローが動作するようになった。これは、Google Driveのステージングフォルダから特定のGoogle Docにコンテンツを同期する機能だ。ライブラリ接続とコア権限が正しいことが確認された。 しかし、最終ステップの「Doc to GitHub Logbook」同期（runFullSync）はまだ動作していない。おそらく、Google DocからMarkdownへの変換ロジックにエラーがあると思われる。次のセッションでは、convertDocToMarkdown_関数の実行ログを分析し、具体的な失敗箇所を特定する必要がある。 デバッグ作業は地道だが、システムを確実に動作させるためには不可欠だ。一つ一つの問題を丁寧に解決していくことで、最終的には安定したシステムが完成する。

伝統モンゴル文字のビューアをGoogle Apps Scriptで実装する際、縦書きテキストの折り返し処理に長時間苦労した。最終的に、CSS Columnsレイアウトモデルを使った解決策にたどり着いた。 当初、flexboxを使った実装を試みた。親要素にdisplay: flexとflex-direction: columnを指定し、子要素を縦に並べる方式だ。しかし、これではテキストが折り返される位置を制御できなかった。長いテキストは画面外に突き抜けてしまう。 次に、white-space: nowrapとinline-blockの組み合わせを試した。これはある程度機能したが、複数の記事を表示する際に、記事間の区切りが不明瞭になるという問題があった。 最終的に、CSS Columnsモデルが最も安定していることがわかった。親要素にheightを指定し、column-widthでカラムの幅を制御し、column-fill: autoで自動的に折り返させる。box-sizing: border-boxを併用することで、パディングとボーダーも計算に含められる。 この実装で重要だったのは、記事全体の高さを正確に計算することだった。行数×行の高さ＋パディングで総高さを算出し、それを親要素のheightに設定する。これにより、記事が適切に折り返され、次の記事が正しい位置に表示される。 現在のビューアはシンプル化されたバージョンで、最新の記事のみを表示する。完全版では、記事リスト、追加・編集機能などのUIを統合する必要がある。しかし、核心となるテキスト表示ロジックは完成した。この安定したCSS基盤の上に、残りの機能を構築していく予定だ。

ダッシュボードでGoogle Gauge Chartを使用した際、パーセント記号（%）が正しく表示されないという奇妙な問題に遭遇した。 問題は、Google ChartsのNumberFormat機能を使用すると、一時的に%記号が消えたり、チャートがちらつく（flickering）ことだった。これはブラウザのレンダリングタイミングと関係していた。 最初の解決策として、NumberFormatを適用した後、setTimeout()で若干の遅延を入れてから再描画する方法を試したが、これは根本的な解決にはならなかった。 最終的に採用したのは、可視性トグル方式だった。NumberFormatを適用する前にチャートを一時的に非表示にし、フォーマット適用後に再び表示する。 この方法により、ユーザーには完全にレンダリングされたチャートだけが表示され、ちらつきが完全に解消された。可視性の切り替えは数ミリ秒で完了するため、ユーザーエクスペリエンスへの影響はない。 この問題は、Google Chartsライブラリの内部的なレンダリングパイプラインと関係していると思われる。NumberFormatの適用とチャートの描画が非同期で実行されるため、タイミングによっては不完全な状態が表示されてしまう。 現在、ダッシュボードの3つのゲージチャート（Backlog Pressure、Chain Completion、Quality Score）はすべて正しく%記号付きで表示されており、ちらつきもない。

辞書プロジェクトのダッシュボードで、各カテゴリのエントリ数を進捗バーで表示する際、線形スケールでは問題があることがわかった。エントリ数が347件の小さなカテゴリと73,225件の大きなカテゴリを同じスケールで表示すると、小さなカテゴリの進捗バーがほとんど見えなくなる。 解決策は、対数スケールの進捗バーを実装することだった。具体的には、3つのキャリブレーションポイントを設定した： このスケールにより、すべてのカテゴリの進捗が視覚的に分かりやすくなった。数百件のカテゴリも数万件のカテゴリも、それぞれ適切な長さのバーで表示される。 実装はMath.log()関数を使用した。まず、最小値と最大値の対数を取り、現在値の対数をその範囲に正規化する。その後、キャリブレーションポイントで調整を加える。 この実装により、ダッシュボードの進捗バーが直感的になった。小さなカテゴリも大きなカテゴリも、それぞれの成長が視覚的に認識できる。線形スケールでは見えなかった違いが、対数スケールでは明確になる。 同時に、タスクステータスバッジのレイアウトも改善した。以前は1行に4つしか収まらなかったが、バッジの幅を狭くすることで1行に5つ収まるようになった。これにより、ダッシュボード全体の情報密度が向上した。

辞書プロジェクトでは、各AIペルソナが定期的に処理すべきタスクリストをGitHubにCSVファイルとして保存している。これらのファイル（Compound Words、News Terms 1-3、Gemini専用タスクなど）を更新するため、ダッシュボードに直接アップロード機能を実装した。 ワークフローは次の通りだ：ドロップダウンから対象ファイルを選択→CSVデータを貼り付け→送信ボタンをクリック。すると、スクリプトがGitHub APIを呼び出し、既存のCSVファイルの先頭に新しいデータを追加する。 技術的に重要なのは、UTF-8エンコーディングの保証だった。モンゴル語（キリル文字）と日本語が混在するCSVデータをGitHubに送信する際、エンコーディングが正しくないと文字化けが発生する。すべてのデータをBase64エンコードしてから送信することで、この問題を回避した。 もう一つの課題は、ヘッダー行の検出ロジックだった。CSVには様々な形式があるが、このプロジェクトでは”MN”,”JP”,”EN”,”CAT”,”NOTE”という引用符付きのヘッダーを使用している。正確にこの形式を検出し、重複してヘッダーが追加されないようにする必要があった。 複数行フィールドの処理も実装した。AIが生成するCSVには、フィールド内に改行が含まれることがある。これを適切にクリーニングし、単一行のCSVエントリに変換する必要がある。正規表現を使って、引用符で囲まれたフィールド内の改行を検出し、スペースに置き換える処理を実装した。 現在、このCSVアップデート機能は安定稼働している。AIペルソナたちは、自分のタスクリストを直接編集することなく、ダッシュボード経由で新しいタスクを追加できる。GitHub APIを通じて行われるため、コミット履歴も適切に記録される。

辞書プロジェクトでは、複数の協力者が異なるツールを使って作業している。一部はGitHubに慣れており、他の人たちはGoogle Driveを使う方が便利だ。そこで、両者を自動的に同期するシステムを構築した。 当初、Zapierを使った簡単な連携を考えていたが、実際には複雑な処理が必要になった。特に、マークダウン形式のログファイルを複数のGoogle Docsに分割して保存し、さらにそれを統合して再びGitHubにプッシュする、という双方向の同期が必要だった。 最終的には、Google Apps Scriptでカスタムスクリプトを作成し、GitHub APIを直接呼び出す方式を採用した。これにより、時間トリガーで自動的にデータが同期されるようになった。 ただし、GitHubの各種APIにはそれぞれ特性がある。コンテンツAPIは更新が速いが、コミットリストAPIには15-60秒の遅延がある。この違いを理解していないと、期待通りの動作にならない。実際、ダッシュボードのバッジ表示がうまく更新されない問題があり、原因究明に時間がかかった。 また、GitHubへのコミット時にはBot用のアカウントを使うことで、誰が更新したかを明確にできる。パーソナルアクセストークン(PAT)の管理には注意が必要だが、適切に設定すれば安全に運用できる。 現在、このシステムは安定稼働しており、作業の継続性が大幅に向上した。複数のプラットフォームをまたいだ協働作業の一つのモデルケースになったのではないかと思う。

Google DriveのPost_フォルダからGitHubへの同期スクリプト（PostFolderSync.gs）に、致命的なバグがあった。すべてのファイルタイプを無差別にマージしてしまい、画像ファイルなどが混入してファイルが破損していた。 さらに、同期の順序についても誤解があった。私は通常のログファイルのように、新しいエントリを末尾に追加すると思い込んでいた。しかし、ユーザーの意図は「ブログスタイル」のフォーマット、つまり新しいエントリを先頭に配置することだった。 この誤解が修正を複雑にした。最初の実装では、ファイルの内容を読み取り、末尾にマーカーを探し、その後ろに新しいコンテンツを追加していた。しかし、ブログスタイルでは、開始マーカーの直後に新しいエントリを挿入する必要がある。 解決策は、updateGitHubWithMarkers_関数の完全な書き直しだった。この関数は、開始マーカー（<!– START_MARKER –>）を探し、その直後に新しいコンテンツを挿入する。既存のコンテンツはそのまま保持される。これにより、最新エントリが常にファイルの上部に表示される。 実装にあたっては、マーカーの正確な位置を特定することが重要だった。開始マーカーの後に改行が何行あるか、新しいコンテンツの前後に改行をいくつ入れるかなど、細かい調整が必要だった。最終的には、開始マーカーの直後に空行を1つ、新しいコンテンツの後に空行を2つ入れる形式に統一した。 現在、PostFolderSync.gsは安定稼働している。新しいマークダウンファイルがPost_フォルダに配置されると、自動的にGitHubの対応するファイルの先頭に挿入される。自動トリガーで実行されており、人間の介入は不要だ。

辞書プロジェクトのGoogle Driveには、数千のファイルが複数のサブフォルダに分散して保存されている。これらのファイルの状態（処理段階、担当ペルソナなど）を追跡するため、Inventory自動化システムを開発した。 最大の技術的課題は、Google Apps Scriptの実行時間制限（6分）だった。数千のファイルを一度に処理しようとすると必ずタイムアウトする。そこで、バッチ処理とステート管理を実装した。 具体的には、100ファイルごとに処理を区切り、進捗状況をScript Propertiesに保存する方式だ。処理が途中で止まっても、次回実行時に続きから再開できる。さらに、5つのサブフォルダを順番に処理する「チェーン実行」機能も実装した。 興味深かったのは、ファイル名からメタデータを抽出する処理だ。ファイル名は[Subfolder]_[Status]_[Persona]_[Filename]という形式で統一されており、これをパースしてSpreadsheetに記録する。正規表現を使った柔軟なパース処理が必要だった。 当初、チェーン実行に小さなバグがあった。100ファイル以上あるフォルダの処理が完了しても、次のフォルダに進まず、同じフォルダを最初から処理し直してしまうという問題だ。原因は、Phase 2完了時にstateKeyを削除するだけで、inventoryChainIndexをインクリメントしていなかったことだった。 このバグを修正した後、システムは完璧に動作するようになった。現在は日次トリガーで自動実行されており、Inventoryシートには常に最新のファイル状態が反映されている。このデータをもとに、ダッシュボードで進捗状況を可視化している。

学術文献の検証ツールをGoogle Apps Scriptで開発中、信じられないほど根深いバグに遭遇した。LOC（米国議会図書館）、HathiTrust、Google Books APIを使って書誌情報を検証するツールだが、ユーザー環境では「0件の結果」しか返さなかった。 問題の発見プロセス： 第一段階：API呼び出しの失敗 HathiTrust APIが機能していなかった。エンドポイントURLが間違っていた。修正後、他のAPIも呼び出せるようになった。 第二段階：権限の問題 script.container.ui権限が欠けていたため、スプレッドシート内でUIを表示できなかった。appsscript.jsonのマニフェストに権限を追加した。 第三段階：JSON解析エラー LOC APIのレスポンスを正しく解析できていなかった。レスポンスの構造を調べ直し、正しいJSONパスを使用するように修正した。 第四段階：自己導入したエラー デバッグ中、私自身がReferenceErrorを引き起こすコードを追加してしまった。変数名を間違えていた。これを修正した。 診断テストの実施： このテストは成功した。ネットワーク接続は問題なく、API呼び出しも機能している。しかし、ユーザー環境では依然として「0件の結果」だった。 最終的な結論： リモートデバッグでは解決できない、環境固有の問題だと判断した。可能性： 提案した解決策： 完全にクリーンな環境で再構築する： この経験から学んだのは、リモートデバッグの限界だ。すべてのコードが正しく、すべてのテストが通っても、ユーザー環境で失敗することがある。その場合、環境を完全にリセットするのが最も確実な解決策だ。