エージェントによるドキュメント編集に有望な Paper Office

Paper Officeの紹介

skills

本日、Paper Officeをリリースします。これは、既存のオープンソースパッケージであるpython-docx、python-pptx、OpenPyxlを基盤とし、エージェントがWord、PowerPoint、Excelファイルを、安全性、正確性、および網羅性を高めて操作できるようにするPythonパッケージ群です。5つのモデルと61のタスクにわたる評価で、Paperパッケージとガイダンスを組み合わせた場合、92.5%の試行で成功しました。これは、スキルを持たないアップストリームパッケージの80.7%、Anthropicの類似のOfficeスキルを使用した際の69.5%を上回ります。また、エージェントがOfficeファイルの内部を直接編集するコードを記述したのは、Paper実行のわずか1.6%でした。これは、スキルを持たない場合の78.7%、Anthropicのスキルを使用した際の50.5%と比較して大幅な改善です。プロンプト、スキル、ツールに加えて、基本的なソフトウェアも最適化の重要な要素であり続けることを指摘します。

Brownfield Knowledge Work

コンサルタント、弁護士、銀行家、オペレーターの日々の業務において、エージェントの普及率は依然として低いままです。専門家による導入のボトルネックは、実際のワークフローへの忠実性にあると考えています。エージェントは、人間が行うのと同じ手法で既存のドキュメントを操作できず、結果として作成されるデッキ、シート、ドキュメントは、クライアント消費には不向きな、不気味な谷に位置しています。

DOCX、PPTX、XLSXファイルはOffice Open XML（OOXML）を使用しています。それぞれがXMLファイル、画像、その他のリソースをリンクさせたZIPアーカイブであり、単一のテキストファイルではありません。これらのファイルを編集するには、それらの部分とその関係性を一貫して保つ必要があり、たとえ小さな視覚的な変更であっても、複数の場所での更新が必要になる場合があります。

標準的なPython Officeライブラリ（python-docx、python-pptx、openpyxl）は、長年にわたって蓄積されたエッジケースを持つ成熟した構築ツールであり、ほとんどのプロダクションエージェントはドキュメント操作にこれらのライブラリを依存しています。しかし、これらのライブラリは数年間更新されておらず、多くの重要なワークフローにおいて、機能の網羅性や正確性の契約が不足しています。場合によっては、モデルはより簡単にクラシックなOfficeドキュメントを表現・操作するために、他のJavaScriptベースのパッケージやHTMLからドキュメントへのプロセスを選択しますが、これらの中間表現は情報を失いやすく、既存のブラウンフィールド作業を破損させることがよくあります。

標準的なPython OfficeライブラリのAPIをフォーク、パッチ、および再構築し、エージェント中心のさまざまなユースケースをサポートするように、正確性を向上させ、機能の網羅性を拡張しました。

ファイルを編集するエージェントは、しばしば以下を行う必要があります。

• テキストが要素に分割されている場合やテンプレートから継承されている場合でも、ユーザーが参照する論理オブジェクトを見つける。
• フォーマットと関係性を維持しながら、要求された変更を適用する。
• ライブラリが理解しないパッケージ部分を含む、要求されたスコープ外のすべてを保持する。
• 保存された成果物を再度開き、意図した効果がシリアライゼーションを生き残ったことを確認する。

パッケージがこれらの操作を表現できない場合、モデルはラッパースクリプトや生のOOXMLにフォールバックし、パッケージのメカニズムでコンテキストを汚染します。これは、コメントアンカー、チャートワークブック、フィールド、カスタムXML、数式依存関係などにおいて、サイレントなリグレッションを頻繁に引き起こします。

Paper Office Packages

Paper Officeは、馴染みのあるインポートを維持し、それらの下にあるパッケージを拡張します。既存のモデルの事前知識は依然として役立ちます：import docx、from pptx import Presentation、およびimport openpyxlは引き続き機能します。

追加機能は、隠された構造を型付けされた機械可読データとして公開し、サポートされる編集の前にターゲットを検証し、パッケージを保持する保存パスを提供し、境界付けられた変更を報告し、操作が安全に処理できない場合に明示的に拒否します。

Paper DOCX

概要

paper-docxは、ドキュメント全体の検索、変更履歴の追跡、コメント、合成、および元に戻せる赤字（redlines）でpython-docxを拡張し、エージェントがWordのネイティブレビューモデルを使用して既存のWordドキュメントを改訂およびレビューできるようにします。

機能を探る

追加機能は、作業に関連しています。

• 実行をまたぐテキスト検索。 docx.searchは、Wordの実行（run）の断片化を横断して正確なテキストを照合し、正規化されたマッチングをオプトインでサポートし、置換、変更履歴の追跡、またはコメントのアンカー付けのためのライブSpanを返します。Spanは変更前に再検証されます。テキストを変更する置換の後でSpanを再取得してください。
• 番号付けの再開。 docx.numbering.restart_numbering()は、既存の定義を保持し、1から再開する新しい番号付けインスタンスを作成します。apply_numbering()はそれを意図した段落に適用します。
• ネイティブWordの赤字。 docx.package.compareは、テキストとテーブル行の変更をWordネイティブの変更履歴として出力し、プライベートコピーで受け入れおよび拒否の結果の両方を検証し、安全に表現できない違いを拒否します。
• レビューの解決とコメントスレッド。 doc.revisionsは、サポートされているリビジョンを列挙し、それらをアトミックに受け入れるか拒否します。remaining_unsupported()は、別のツールを必要とする形式を特定します。docx.commentopsは、返信、アンカー、および解決状態を接続されたスレッドとして管理します。
• コンテンツコントロール。 docx.controlsは、型付けされた値でサポートされているコントロールを埋めます。サポートされているデータバインドテキストの更新は、表示テキストをカスタムXMLストアと同期させます。サポートされていないバインドタイプ、ロックされたコントロール、および安全でない構造は拒否されます。
• フィールドとブックマーク。 docx.bookmarksおよびdocx.fieldsは、Span上にブックマークを作成し、ページ番号、日付、相互参照、目次をフィールドとしてプレースホルダー結果とともに作成します。
• ドキュメント間合成。 docx.compositionは、フォーマットされたコンテンツをドキュメント間でコピーし、スタイル、番号付け、メディア、ハイパーリンク、ブックマークを調整し、触れたすべての部分を報告します。
• パッケージ差分と保存。 docx.package.patch_saveは、意味的に変更されていないパッケージ部分の元のバイトを復元します。diff_packageおよびtext_diffは変更を報告し、diagnoseは読み取れないパッケージを説明します。通常のDocument.save()は出力を検証しますが、バイト単位で最小限のシリアライゼーションを約束するものではありません。
• ドキュメント保護。 docx.protectionは、Paperの変更をアクティブな制限モードに対してチェックします。コメントのみの保護はコメント操作を許可し、フォーム保護はサポートされているフォーム更新を許可します。明示的な確認は、保護設定を削除せずにガードをオーバーライドします。

フォークは、docx.storyを介して本文、ヘッダー、フッター、脚注、末脚注、コメント、変更履歴の挿入、コンテンツコントロール、およびテキストボックスをトラバースし、リビジョンビューと読み取れないブラインド領域のカウントも提供します。

Paper PPTX

概要

paper-pptxは、継承されたフォーマットの検査、ネイティブの箇条書き、保護されたスライドとシェイプの編集、デッキ間の合成、および構造差分でpython-pptxを拡張し、PowerPointファイルの外科的な差分検出を可能にします。

機能を探る

追加機能は、作業に関連しています。

• 効果的なフォーマット検査。 pptx.inspect、inspect_text、およびinspect_deckは、プレースホルダー、レイアウト、マスター、およびテーマチェーンを通じて、プロビナンスとコンテンツフィンガープリントされたBlockAnchorターゲットを解決した、サポートされているフォント、段落、およびシェイプのフォーマットを解決します。サポートされていない値は未解決としてマークされ、読み取れない領域はカウントされます。
• フォーマットを保持するテキスト置換。 pptx.edit.replace_text、replace_text_at、およびrefindは、影響を受けていない実行を保持しながらテキストを置換し、アンカーされた編集は古いコンテンツを検出し、間違ったテキストに変更が着地する前に拒否します。
• 関係性を安全に保つスライドクローン。 prs.slides.clone()、delete()、reorder()、およびmove()は関係性を安全に保ちます。クローンされたチャートは独立した埋め込みワークブックを受け取り、サポートされていない関係性は型付けされた拒否を発生させます。
• パッケージを安全に保つシェイプ編集。 SlideShapes.delete()、move()、およびadd_copy()は、所有権を保持しながらシェイプを編集し、名前によるグループ認識検索は曖昧な名前を拒否し、呼び出し元に曖昧さの解消を求めます。
• マージされたセルのテーブル編集。 Table.insert_row()、delete_row()、insert_column()、およびdelete_column()は、グリッドを一貫して保ち、影響を受けるセルでのマージされた領域を保護します。
• 箇条書き、番号付け、およびノート。 Paragraph.bulletおよびTextFrame.normalize_autofit()は、実際の箇条書きを作成し、継承された自動フィットを明示的にします。Slide.read_notes_text()は、ノートパートを作成せずに読み取ります。replace_notes_text()は既存のノート本文を編集します。
• 安全な画像とチャートの更新。 Picture.replace_image()は、画像パートが共有されている場合でも、位置とクロップを保持しながらターゲット画像を交換します。Chart.replace_data_safe()は、ターゲットチャートとワークブック構造を検証し、共有チャートパートとサポートされていないチャートファミリを拒否します。
• ポリシーベースのスライドとデッキのインポート。 Presentation.import_slide()およびappend_deck()は、明示的な調整モードを必要とします。宛先テーマを採用する、ソースの外観を維持する、または効果的な値を明示的なフォーマットに焼き付ける。これらは、インポートされた各スライドに対してImportReportを返します。
• レイアウトの再バインド。 Slide.rebind_layout()は、明示的なプレースホルダーと孤児ポリシーの下でスライドを別のレイアウトに移動し、そのRebindReportは、解決された外観が変更されたすべての実行を特定します。
• ライブスライド番号と日付フィールド。 Presentation.apply_footers()およびSlide.apply_footers()は、フッタープレースホルダーにバインドされたネイティブa:fld要素を作成します。日付フォーマットはdatetime1からdatetime13を使用します。fixed_dateはリテラルテキストを書き込みます。
• パッケージを保持する保存。 pptx.package.patch_save()は、意味的に変更されていないメンバーの元のバイトを復元するため、関連のないシリアライゼーション変更が配信パッケージに表示される必要はありません。
• 永続IDデッキ差分。 pptx.diff.diff_decksは、共通の祖先から派生したデッキの構造的な変更を報告します。detail="text"はテキスト、チャートデータ、およびノートの差分を追加します。detail="full"は、解決された実行フォーマットと箇条書きの変更を追加します。

取り込みも強化されています。パッケージは、重複または大文字小文字を区別するメンバー、非標準パス、暗号化、およびサポートされていない圧縮を含む、曖昧または安全でないZIPアーカイブを拒否します。パスベースの保存は、ディスク上にアーカイブを構築し、ZIPの一貫性を検証し、シリアライゼーションが成功した後にアトミックに宛先を置き換えます。

Paper XLSX

概要

paper-xlsxは、パッケージを保持する保存、参照を意識した構造編集、編集レシート、およびLibreOfficeベースの再計算でopenpyxlを拡張し、数式、依存関係、およびパッケージコンテンツを考慮した差分をサポートします。

機能を探る

追加機能は、作業に関連しています。

• ターゲットを絞ったワークブック検査。 wb.sheetnames、境界付けられたセル範囲、およびwb.defined_namesなどの標準的なサーフェスは、出発点として機能します。wb.search()は、値と数式でテキストまたは正規表現の照合を見つけます。ws.allowed_values(cell)は、検証から派生した選択肢を報告します。
• 参照を意識した構造編集。 サポートされている行、列、シート、および範囲操作は、依存する数式、名前、印刷領域、テーブル範囲、およびチャート参照を更新するか、拒否します。行と列の挿入および削除はAddressRemapを返します。シートの名前変更とmove_range()は返しません。
• 保存モードオブジェクト編集。 copy_format()はフォーマットをコピーします。chart.repoint()は値シリーズを更新し、古いキャッシュを削除します。ws.append_table_row()はサポートされているテーブルをアトミックに拡張します。ws.replace_image()は、描画を書き直さずにロードされた画像を1つ置き換えます。カテゴリ範囲と意図されたビジネススコープは、依然として明示的な注意が必要です。
• 数式キャッシュの鮮度。 数式にフィードする可能性のある数式編集と入力変更は、保持されているキャッシュされた結果を無効にし、開いたときの再計算を要求します。スタイルのみの編集や関連のない値の編集は、キャッシュを保持します。再計算まで、データのみのリーダーはNoneを見る可能性があります。Paperは数式自体を計算しません。
• エラー検査と差分。 openpyxl.preserve.scan_errors()は、LibreOfficeなしで数式とキャッシュ/値のエラー表現を検査します。diff_workbooks(..., remaps=())は、構造編集によってシフトされたセルからコンテンツ変更を分離します。
• 編集レシート。 wb.save(..., receipt=True)は、変更されたセルと部分の名前を付けたEditReceiptを返します。wb.validate()は、書き込まずに保存検証を実行します。レシートには、エージェントが明示的に編集したセルだけでなく、数式キャッシュの無効化も含まれる場合があります。
• LibreOffice再計算と認定。 oracle.recalc()は一時的なコピーを再計算し、エラーをスキャンし、output_pathを介して別のPaperで保存された候補を書き込むことができます。oracle.certify()は、LibreOfficeがキャッシュされた値をCERTIFIED、DIVERGED、またはBASELINE_UNVERIFIABLEとして再現するかどうかを報告します。oracle.evaluate()およびoracle.evaluate_many()は、一時的な入力を適用し、要求された出力を返します。これらの操作はソースを上書きすることはなく、保存にはLibreOfficeは必要ありません。
• 保護とピボット更新。 ロックされたセルへの書き込みは警告を発する可能性があります。wb.strict_protection = Trueは、それらを拒否させます。wb.set_pivot_refresh_on_load()は、依存する編集に対する明示的な同意を与え、Excelに開いたときに選択されたピボットを更新するように求めます。それらのキャッシュされた結果は、その更新まで古いままです。

パス保存はディスク上にアーカイブを構築し、ZIPの一貫性を検証し、シリアライゼーションが成功した後に名前変更を行います。呼び出し元は、固定のパッケージ全体サイズまたは圧縮率制限ではなく、リソース予算を制御します。

Experimental Design

報告された比較は、61のタスク（DOCX 27、PPTX 15、XLSX 19）をカバーしています。これには、断片化されたテキスト、リビジョン、コメントスレッド、番号付け、フィールド、スライド関係、埋め込みワークブック、テンプレート系統、数式、名前、チャート、および依存範囲を含む、さまざまな既存ファイルワークフローと、2つの作成コントロールが含まれます。

5つのモデルを評価しました：Opus 5、GLM 5.3 Flash、GPT 5.6 Sol、Grok 4.6、およびDeepSeek v4.1 Flash。各モデルとタスクのペアは、3つの条件の下で展開されました。

すべての条件は、OpenCode in Harborで実行され、条件間で同一のタスクプロンプトが使用されました。

両方のアップストリーム条件は、同じピン留めバージョンを使用しました：python-docx==1.2.0、python-pptx==1.0.2、およびopenpyxl==3.1.5。

Task Success

モデル別のタスク成功率

フォーマット

レガシーパッケージ
レガシー + Anthropic スキル
Paper パッケージ

Paperは305試行中282回（92.5%）で成功しました。これは、アップストリームの生データでは305試行中246回（80.7%）、Anthropicスキルを使用した場合では305試行中212回（69.5%）でした。

Performance by Slice

フォーマット別のタスク成功率

モデル

レガシーパッケージ
レガシー + Anthropic スキル
Paper パッケージ

スキルなしと比較して、Paperは15のモデル別フォーマットスライス中12で成功率を向上させ、DeepSeekのPPTXとXLSXでは同等、GLMのPPTXでは1タスクだけ劣りました。モデル全体で集計すると：

• DOCX: スキルなしで83.0%、Anthropicスキルありで84.4%、Paperありで96.3%。
• PPTX: スキルなしで84.0%、Anthropicスキルありで74.7%、Paperありで92.0%。
• XLSX: スキルなしで74.7%、Anthropicスキルありで44.2%、Paperありで87.4%。

Trajectory Analysis

主な違いは、ファイル内部の簿記を誰が処理したかでした。レビューされたアップストリームの実行では、エージェントはコメントの再接続、スライド関係のコピー、またはスプレッドシート参照とキャッシュの修復のためにコードを記述することがよくありました。一部はこれを成功させました。Paperは通常、APIを介してその作業を処理しましたが、エージェントは依然としてXMLを検査して結果を確認しました。保持された全915回の実行において、明示的な生のZIP編集コードは、アップストリームパッケージでより頻繁に現れました。

OOXML内部への直接編集

実行内でエージェントがOfficeアーカイブ内のファイルを直接更新するコードを記述した回数。試行とスクラッチテストを含む。

レビューされたケースでの繰り返し発生した失敗は、不完全な編集でした。要求されたテキストまたは数値は正しかったものの、コメントリンク、依存範囲、またはファイルの無関係な部分がそうではありませんでした。Paperはこれらの接続された変更を支援しました。

軌跡の振る舞いをカウントする方法

61のタスク全体で、各モデル、タスク、および条件の選択された実行を分析しました。チャートは、エージェント提出コードに明示的な.writestr(...)呼び出しが含まれている場合、実行を1回カウントします。インラインPython、スクリプトheredoc、ファイル書き込み、編集、および追加されたパッチ行を通じて提出されたソースを検査し、返されたドキュメントとライブラリソースは除外しました。

試行全体で、Paperはアップストリームの実行が見逃した数式エラーを見つけ、スレッドが編集されたときにコメントの返信を添付し、列が挿入されたときにスプレッドシートの検証とフォーマット範囲を更新しました。編集が簡単であっても、Paperなしではモデルはしばしば周囲のドキュメントを微妙な方法で破損させました。

以下の例は、同じモデルが各セットアップで同じタスクをどのように完了したかを比較しています。

例1：DOCXコメント

DeepSeekは、既存のコメントを拡張し、返信を追加し、別の議論を開いたままにして会話を解決済みとしてマークするように求められました。スキルなしのアップストリームパッケージを使用した場合、要求されたテキストを追加しましたが、返信を接続するリンクと会話の解決済みステータスを記録するリンクを正しく更新しませんでした。PaperはコメントAPIを介してこれらのリンクを維持しましたが、Anthropicスキルを使用したエージェントは手動で更新しました。スキルなしのバージョンが失敗したのに対し、両方とも合格しました。

例2：PPTXスライドコピー

Grokは、元のスライドに影響を与えずに、スライドをコピーしてそのコピーのチャートとスピーカーノートを変更するように求められました。3つのセットアップすべてが、チャートとノートを独立して保持するためのチェックに合格しました。アップストリームパッケージで作成されたコピーは、元のスライドからの内部作成識別子を保持しており、これが唯一の失敗したチェックでした。Paperはスライドをコピーする際に新しい識別子を割り当て、すべてのチェックに合格しました。

例3：XLSX予測更新

GLMは、予測四半期を追加し、チャートと年間合計を更新するように求められました。3つのセットアップすべてが、収益485、EBITDA 111という正しい数値に達しました。アップストリームパッケージでは、一部の入力検証とフォーマットルールが古いセル範囲にまだ適用されており、スキルなしのエージェントはチャートに古い四半期を残しました。Paperは依存範囲を更新し、エージェントはすべてのチェックに合格したワークブックを生成しました。他の2つのセットアップは合計を正しくしましたが、ワークブックの一部を古いままにしました。

別のスプレッドシートタスクでは、GPT 5.6 Solがファイルを変更せずに数式エラーを特定するように求められました。Paperのscan_errors()を使用したところ、数式と格納された計算結果に必要な4つのエラーすべてを見つけました。アップストリームのセットアップでは、両方とも2つしか見つけませんでした。Paperの結果は合格し、ワークブックは変更されませんでした。

Software as a Performance Lever

5つのモデル全体で、Paperパッケージは包括的なタスク成功率を向上させ、知識労働の問題に対するエージェントのパフォーマンスを向上させるための重要なレバーとしてソフトウェアを強調しています。

Featherハーネス内でデフォルトでPaper Officeを使用しています。パッケージの詳細についてはこちらをご覧ください。

すべてのタスクはこちらで確認できます。

---

Citation

Khazi, Daanish; Bains, Gavin; and Besgen, Joey, "Introducing Paper Office",
Paper Instruments Blog, September 23, 2026.

@misc{khazietal2026paperoffice,
  author = {Daanish Khazi and Gavin Bains and Joey Besgen},
  title = {Introducing Paper Office},
  howpublished = {Paper Instruments Blog},
  year = {2026},
  month = {September},
  url = {https://www.paperinstruments.com/blog/introducing-paper-office}
}