thesis-docx

Thesis DOCX

概要

内容の品質と書式の忠実性の両方が重要な、論文向けの .docx 作業にはこのスキルを使用してください。バッチ書式設定、スタイル、キャプション、ページ割り、目次、相互参照を扱う作業では、WPS のような代替ツールよりも Microsoft Word のデスクトップ自動化を優先してください。

このスキルは、論文の編集で最もよくある失敗を避けるために設計されています。エージェントが早い段階で広範囲な書式変更を行い、新たなレイアウトの問題を引き起こしたうえ、ユーザーに一つずつ見つけさせてしまう失敗です。そのため、デフォルトの動作は次のとおりです。

1. まず監査する
2. 明示された学校の要件と、指定されていない書式を分ける
3. 根拠のある修正だけを行う
4. 完了を伝える前に、ページごとに再確認する

ワークフロー

1. 最初に Microsoft Word と COM/DOM の自動化を確認します。
   • Windows では、次を実行します。

   powershell -ExecutionPolicy Bypass -File scripts/check_word_com.ps1 -Json
   

   • Word がインストールされていない場合、COM を利用できない場合、または DOM にアクセスできない場合：
     • 自動化を多用する計画を中止します。
     • デスクトップ版 Microsoft Word をインストールするようユーザーに伝えます。
     • 論文の書式設定では、WPS などの類似ツールを使用するとレイアウトの再現性が損なわれる可能性が高いことを簡潔に説明します。
2. 編集を始める前に、ユーザーの実際の制約を確認します。
   • 論文のテンプレート、学校の書式ガイド、スクリーンショット、既存の文書、サンプルページ、明示された章ごとの規則を収集します。
   • ユーザーが正式な要件を示した場合は、それに厳密に従います。
   • ユーザーが要件を示していない場合は、学校固有の基準を作り出さないでください。一般的で保守的な学術上の既定値を用い、それが既定値であることを伝えます。
   • 編集前に、要件を次の 2 つに明確に分類します。
     • must enforce：学校のガイド、テンプレート、ユーザーが確認したスタイル規則
     • preserve current state：学校のガイドで定められていないすべての事項
3. リスクの高い一括編集を行う前に、DOCX / OOXML を監査します。
   • 大規模な書式設定の前には、scripts/audit_docx_ooxml.py の使用を優先します。
   • 修正方法を決める前に、隠れたインデント、セクションのずれ、古い REF 表示テキスト、スタイル ID の不一致を検出するために使用します。
4. 散在する直接書式ではなく、スタイルを使って標準化します。
   • 可能な限り、既存のスタイルを再利用し、修正します。
   • 一致するスタイルが存在しない場合に限り、不足しているスタイルを作成します。
   • 本文、見出し、図のキャプション、表のキャプション、参考文献、要旨、付録のスタイルを分け、一貫性を保ちます。
   • スタイルを全体的に変更する前に、文書に、その変更後も残る直接の段落書式や OOXML の上書き設定がないか確認します。
5. 内容の編集には、ユーザーが提供した事実のみを使用します。
   • 論文の文章の加筆、推敲、再構成は、ユーザーのテーマ、根拠、コードベース、メモ、資料の範囲内でのみ行います。
   • 実験データ、システム構造、エンティティ、結果を作り出さないでください。
   • エージェントの推論やデータを与えた背景を、論文の文章に書かないでください。次のような論文らしくない表現は禁止します。
     • 「已有工程に基づいて」
     • 「既存コードに基づいて」
     • 「タスク指示書とコードをモデルに入力した後」
     • 「ユーザーから提供されたコードの分析を通じて」
     • AI の作業メモのように聞こえ、論文の文章にふさわしくないあらゆる表現
   • プロンプトエンジニアリングの文体、レビューの文体、思考連鎖の文体ではなく、一般的な論文の文体で書きます。
   • 「本稿では……を設計・実装しました」「システムでは……を採用しました」「このモジュールでは……」のように、学生の文章として自然に読める中立的な学術表現を優先します。
   • 文章の生成、推論、組み立て方法を説明する、一次的なメタ説明は避けます。
6. 図の生成は、資料が十分にある場合に限ります。
   • アーキテクチャ図、E-R 図、フローチャート、状態図など、論文の図には Mermaid を使用します。
   • 各ノード、フィールド、関係、依存関係はすべて、コード、SQL スキーマ、API ドキュメント、プロジェクト資料、論文の草稿など、ユーザーから提供された実際の資料に基づかせます。
   • 資料が不十分な場合は、図を捏造せず、不足している情報の提供を求めます。
7. 論文に掲載するコード抜粋には、LaTeX の慣習に沿った組版を行います。
   • 議論に関係するコードだけを残します。
   • ユーザーのコードまたは設計にある実際の識別子を保持します。
   • 完成度があるように見せるだけの架空の補足コードは避けます。
8. 完了を伝える前に監査します。
   • まず構造を監査します。対象はスタイル、セクション、キャプション、参考文献、ページ番号の方式、相互参照、隠れた段落の上書き設定です。
   • 次に Word から文書を PDF にエクスポートし、ページごとに確認します。
   • PDF レベルの監査に合格した場合、または未完了の目視確認を明確に伝えた場合に限り、タスクが完了したと伝えます。

スタイル戦略

• 書式設定の唯一の基準としてスタイルを扱ってください。
• 次の論理的なスタイル区分を優先してください。
  • Body Text
  • Heading 1 / Heading 2 / Heading 3
  • Figure Caption
  • Table Caption
  • References
  • Abstract
  • Keywords
  • Appendix Title
• 文書にすでに同等のスタイルがある場合は、それらに対応付けて、フォント、間隔、インデント、番号付けの動作を統一してください。
• 直接書式設定がスタイルと競合する場合は、直接書式設定を減らし、文書をスタイルで管理される状態に戻してください。
• 学校のガイドで指定されていないセクションを全体的に統一しないでください。 過剰な変更につながるリスクが高い例：
  • ユーザーが見出しだけを依頼しているのに、ページヘッダー／フッターを再設計する
  • 参考文献だけが作業対象なのに、コードボックスの外観を変更する
  • 学校のガイドで規定されていないのに、表の内部を統一する
• スタイルを統一した後も視覚的な問題が残る場合は、firstLineChars、番号付けのインデント、titlePg、differentFirstPageHeaderFooter、REF フィールドの表示テキスト、直接適用された文字列の書式設定など、非表示の OOXML 状態を調べてください。

監査を先行する方針

一括編集の前に、次のようなチェックリストを作成し、それに沿って作業してください。

1. 学校のガイドで明示的に規定されている箇所はどこですか？
2. ユーザーが独自に定めたルールはどこですか？
3. 現状で問題がなく、維持すべき箇所はどこですか？
4. 問題は構造上のものですか、それとも見た目だけのものですか？
5. スタイルを使って安全に修正できる箇所はどこですか？
6. Word COM または OOXML レベルの修正が必要な箇所はどこですか？

構造の監査結果が良好だからというだけで「完了」としないでください。論文では、ページ割り付けとページ単位のレンダリングも正しさの一部です。

リスクの高い落とし穴

大規模な書式設定作業の前に、references/failure-patterns-and-quality-gates.md を読んでください。特に、次の問題が起きないよう注意してください。

• 正しく見えるものの、誤ったスタイル ID に対応付けられているスタイル名
• 意図したスタイルを上書きする、段落レベルの直接書式設定
• 余分なインデントを見えない形で生じさせる firstLineChars や番号付けのインデント
• 古い表示テキストのままになっている目次フィールドや相互参照フィールド
• ヘッダーやページ番号が欠落する原因となる、セクションレベルの先頭ページ設定
• 表の行の高さ、垂直方向の配置、コードボックスのタイトルの切れ方に関する、Word と WPS の違い
• DOI、URL、コード、英語の参考文献を書き換えてしまう句読点の統一

視覚的な確認ルール

学校指定の書式に敏感な論文作業では、最終確認は次の順序を優先してください。

1. Word COM/DOM による構造チェック
2. Word から PDF へのエクスポート
3. PDF の全ページを確認
4. その後にのみ最終成果物を提出

ページのレンダリングを確認できない場合は、書式が完全に検証済みであるかのように示すのではなく、その旨を明記してください。

図のルール

• 論文で図が必要であり、その構造を実際の資料からたどれる場合は、Mermaid を使用してください。
• 図は学術的に中立で簡潔なものにしてください。
• 装飾的なラベル、くだけた吹き出し、推測に基づく要素は避けてください。
• 実際の資料と矛盾しない限り、ユーザーの用語を使用してください。
• 図を生成する前に、references/figure-and-code-rules.md を読んでください。

論文の文体ルール

本文を生成または書き直す前に、references/thesis-voice-and-style.md を読んでください。特に、次の点に注意してください。

• 論文の文章は論文らしい文体にし、AI の推論について記すメモのようにしないでください
• 査読のようなメタ的なコメントよりも、学生向けの学術的な叙述を優先してください
• ソースの読み込み、コードの取り込み、分析の手順が最終的な論文本文に現れないようにしてください

論文の文章を確定する前に、次の点を簡潔に自己確認してください。

1. その段落は、アシスタントがどのように推論したかではなく、システムや研究そのものを説明していますか？
2. その段落は、プロンプトのメモではなく、論文の叙述として自然に読めますか？
3. 「既存のコードによると」、「既存のプロジェクトによると」、「ユーザーから提供されたコードを分析した結果」など、作業手順を示す表現を避けていますか？
4. 読者が AI の支援を受けて書かれたと知らなくても、その文は意味が通じますか？

コード掲載ルール

• 論文にコード掲載が含まれる場合は、LaTeX を用いたコードの提示を優先してください。
• 掲載するコードは実際のコードに忠実にしてください。
• 論文の論旨を支えない場合は、必須ではない定型コードを省いてください。
• ユーザーが特定の LaTeX パッケージまたは掲載スタイルを指定した場合は、それに従ってください。

リソースガイド

• scripts/check_word_com.ps1
  • Microsoft Word デスクトップ版と COM／DOM オートメーションが利用可能かどうかを確認します。
• scripts/audit_docx_ooxml.py
  • リスクの高い書式変更を行う前に、DOCX のスタイル、直接指定されたインデント、セクション設定、番号付け、REF フィールドの動作を監査します。
• scripts/normalize_word_styles.ps1
  • Word COM オートメーションを使用して、論文本文、Heading 1-3、図のキャプション、表のキャプションを一括で標準化します。
• scripts/export_word_pdf.ps1
  • Word COM を使用して、現在の論文文書を PDF にエクスポートし、ページ単位で確認します。
• scripts/render_mermaid_figure.ps1
  • Mermaid ソースを論文用の SVG、PNG、または PDF 図版に変換します。
• references/paper-format-workflow.md
  • 標準的な Word 論文の書式設定ワークフローを確認するために読みます。
• references/figure-and-code-rules.md
  • Mermaid 図または LaTeX コード掲載を生成する前に読みます。
• references/thesis-voice-and-style.md
  • 論文の文章を生成または書き換える前に読みます。
• references/failure-patterns-and-quality-gates.md
  • 大規模な書式設定を行う前、または論文を完全に確認済みとする前に読みます。
• references/script-usage.md
  • コマンドの例と設定ファイルの規則を確認するために読みます。

最終確認

• 編集後も文書がスタイル駆動であることを確認してください。
• キャプション、番号付け、改ページ、目次に一貫性があることを確認してください。
• 相互参照に、古いフィールドテキストではなく現在の参照先ラベルが表示されることを確認してください。
• セクション設定によって、先頭ページのページヘッダーやページ番号が意図せず削除されていないことを確認してください。
• 参考文献が学校の規則に従って書式設定されていること、句読点の標準化によって DOI や英語の参考文献が損なわれていないことを確認してください。
• すべての図とコードブロックがユーザー提供の資料に基づいていることを確認してください。
• 書式が完成したと伝える前に、PDF にエクスポートし、すべてのページを確認してください。
• Word オートメーションまたは PDF による検証が利用できなかった場合は、レイアウトの忠実性が保証されないことを明示してください。