はじめに
2026年6月11日〜2026年6月18日の一週間は、法人設立後の手続き管理・複数クライアントの会計レビュー・購買システムの自動化・ナレッジ基盤の再設計・マネタイズ商品基盤の構築と、幅広い領域が同時並行で動いた週でした。技術実装・会計実務・法人手続き・ナレッジ基盤整備・事業開発にまたがる約15件以上のトピックが進行し、それぞれが対話ログ・スキル・引継ぎ文書として知識管理システムに記録・整備されました。以下、各トピックを順に紹介します。
法人設立後フェーズの手続き管理と引継ぎ文書整備
法人設立後に残る各種手続きについて、今週は複数回にわたって引継ぎ文書の整備と差分の同期を行いました。
社会保険の新規適用届はまだ処理中の状態が続いており、この処理完了が本人の健康保険・厚生年金への加入届出、配偶者の被扶養者届・第3号届、そして国民健康保険の脱退という一連の連鎖手続きの起点となっています。手続きの順序依存を明確化した完全自己完結型の引継ぎ文書を作成し、次回のチャットセッションでも迷わず着手できるよう整備しました。
今週確定した差分としては、都税事務所への法人設立・設置届の手続きが完了しエレクトロニックな申請ルートでの2件がすべて完了したこと、法人口座の開設が完了し法人名義でのログインが稼働したこと、この2点が挙げられます。一方で、社会保険の適用届については引き続き処理中であり、これが唯一のクリティカルパスとして明確化されています。
また、23区内の都税事務所は税目によって所管が分かれる仕組みであることが今週の調査で確認されました。法人事業税・法人都民税と事業所税とでは担当する事務所が異なるケースがあり、この構造的な理解をスキル文書に追記しました。
引継ぎ文書は標準8セクション構成で、現状確認・残タスクの順序依存・戦略的学びを原文転記する形式で整備されており、各セッションを通じて最新版が前版を置き換える形で更新されています。機微情報（申請番号・識別番号・基礎年金番号等）はすべて本文に記載しない運用を一貫して維持しています。
年度連結決算レビューの多段階実施
今週はあるクライアントの年度連結決算について、Phase1からPhase3までの多段階レビューを実施しました。
Phase1では、会計士事務所が作成した連結財務諸表の6月提出版を、openpyxl（data_only値と数式の両モード）とpython-docxで精査しました。連結精算表のシート構造を白紙から実測し（行数の実測再特定を含む）、連結固有処理の全項目合格・連結精算書と損益計算書・株主資本等変動計算書の三者一致を確認しました。最重要発見として、前期黒字から当期純損失への転落が確認されました。営業利益の大幅な縮小と、繰延税金資産の全額取崩が2大要因として特定されています。
Phase2では、関係者間のメール応酬で浮上した「期ズレ調整の振り戻し」仮説と、Phase1で特定した税効果主因仮説との平仄を実数値ブリッジで検証しました。営業段階での利益悪化を「各社単体の粗利縮小」と「連結調整」に二分し、両方が重なって当期純損失につながっている二段構造を確認しました。また、連結調整仕訳の実シートを走査し、対応する売上原価が調整されていない方式が、年度間の取引変動局面において連結損益を歪める構造を実証しました。
Phase3では、期ズレ調整の相殺構造を項目別に全件分解し、歪みの本質が「決算期の違いそのもの」ではなく「期ズレ売上の原価対応付け」にあることを特定しました。また、決算期統一に関する3つの対応案を事実ベースで評価し、最小コストで主因を解消できる方向性についての論点整理を行いました。
最終的に確定した質問リスト（全11問）をMarkdownとExcel両形式で作成し、5分類（構造・連結固有・要注意科目・前期比較・株主資本等変動計算書整合）に整理して、各問に根拠ファイル・シート・金額を付記しました。ExcelはMeiryo・ブランドブルー見出し・交互行などのデザイン設定で仕上げています。これらのレビューはすべて読み取り専用で実施し、元ファイルへの変更はゼロを厳守しています。
予実管理テーブルの構築と引継ぎ整備
あるクライアント向けのFY2026予実管理について、今週は実績投入・フォーマット改修・スクリプト整備・引継ぎ文書作成と、複数の工程を進めました。
まず、仕訳帳CSVから4〜5月の実績を転記する初版を生成しました。3層仕分け（自動確定・要確認・対象外）の枠組みで仕訳を分類し、期首残高開始仕訳の除外・減価償却控除・固定資産取得加算・前払費用化・輸入消費税加算といった実績母数の補正ルールを実装しました。要確認件数については、担当者の判断待ちとして空欄を維持し、分類辞書を同梱して次版への引継ぎを可能にしています。
続いて、7カテゴリ進捗ダッシュボードの先頭シートへの追加・億円から百万円への単位変換・仕訳帳全行のコピーと分類タグ付与・検算ブロックの追加という4つの要望を反映した改修版を生成しました。ダッシュボードのSUMIFS自動集計・検算の三者一致確認・数式エラーゼロをすべて確認しています。
スクリプトは一時フォルダから正規フォルダへ退避し、README・設計注記とともに自己完結する形で保存しました。また、引継ぎ書をWord形式で新規作成し、概要・シート構成・予算構造・実績転記6ルール・分類と運用フロー・検算ブロック・月次運用手順・生成スクリプトの9章構成で第三者が再現できる粒度でまとめました。
引継ぎ書のWord生成後に7章のテキストが先頭1文字のみになる不具合が発見されたため、原因（スクリプトの1行バグ）を特定し、修正版を別名で保存しました。根本原因のスクリプト修正箇所も特定し、次回再生成時の対応方法を申し送りに記載しています。
最後に、次回チャット引継ぎ文書を標準8セクション構成で作成し、現在の状態・月次運用5手順・既知課題・戦略的学びを原文転記しました。スキル化については、対象フォルダは存在するものの内容が未作成であることを実走査で確認し、完遂課題として明記しています。
購買発注ワークフローのコストレポート自動化
あるクライアント向けの購買発注ワークフローについて、今週はコストレポートの可視化機能をGoogle Apps Script（GAS）で実装しました。
当初はPythonによるスプレッドシートの直接読み取りを試みましたが、認証基盤の構造的な制約により実現できないことが確認されました。clasp認証を経由したOAuth経路ではApps Script APIのみが有効でSheets APIが無効であり、この制約はユーザー側では解消できない構造的なものです。これを受けてGAS方式（スプレッドシートにバインドしたスクリプト）に切り替え、GASエディタに貼り付けて使う形式のコード一式を生成しました。
実装した主な機能は以下のとおりです。申請データを読み込んで明細を展開し、本部・担当者・資産消耗品区分・中分類のそれぞれで集計したファクトテーブルを生成します。中分類は辞書シートのキーワードで自動分類し、辞書はコードを変更せずシートへの追記で育てられる設計です。ダッシュボードには本部別・月別・担当者別・資産消耗品別・中分類別の各集計と横棒グラフを出力します。検算ログには毎回の実行結果が追記され、中分類合計とファクトテーブルの合計の一致を自動確認します。
途中でいくつかの不具合に対応しました。金額セルが日付として誤認識される問題については、書き込み前に列書式を明示設定することで解消しました。手動補正が毎回の全件再生成で上書きされる問題については、補正専用シートを設けて毎回再適用する冪等パターンで解消しました。ピボットシートについても、シートが存在しない場合のみ生成し、存在する場合は一切変更しない冪等設計で実装しました。
さらに今週後半には、機材系の購買を担当者・本部別に集計するビューと、3カテゴリの内訳を積み上げ横棒グラフで可視化するビューを追加しました。module軸での集計（module別合計・module×カテゴリのマトリクス・module別上位申請）も追加しています。次回チャット引継ぎ文書を標準8セクション構成で作成し、GASコードの全体構成・既知課題・戦略的学び・環境情報を網羅しています。
購買発注ワークフローの税込直接入力対応
同じクライアントの購買発注ワークフローについて、税込直接入力に対応した改修の実装を完了しました。
Phase1の調査では、現行の金額計算ロジック・承認ルート判定・コストレポートとのデータ連携契約を実走査で確認し、7件の論点を整理して担当者に提示しました。確定した方針は、品目行に「税区分（税抜/税込）」セレクタを追加しつつ、内部保存は常に税抜単価・税込小計に正規化する方式です。これにより、承認ルート判定・コストレポート・下流のデータ契約を一切変更せずに済む設計としました。
Phase3の実装では、申請フォーム・承認者画面・購買担当者画面・バックエンドのスクリプトの4ファイルを改修しました。税区分に応じた単価正規化（税込入力の場合は税抜換算を小数2桁保持）、小計の常時税込保存、タイプ判定への税込合計の受け渡し、既存の申請データとの後方互換性確保を実装しています。また、既存の承認者画面で金額列に小計が表示されない不具合も併せて修正しました。テスト関数7アサーション（税抜・税込両方向の計算確認を含む）を新設し、既存の60シナリオと合わせて回帰確認の仕組みを整えました。
デプロイについては、認証トークンの失効によりこの週では未実施となっており、次回の再認証後にデプロイするよう申し送りに記載しています。バックアップは改修対象4ファイル全てについて作成済みです。
ナレッジ基盤の七層再編と行動原理の確立
今週は、Altinaflyの知識管理システムのフォルダ階層を六層から七層へ再編しました。
これまで「哲学→戦略→実務規約」という三層の間に「どう判断するか」を定めた行動原理の層が欠けていたことが、内部AIエージェントとの対話を通じて明らかになりました。この認識を受けて、行動原理専用の層（書斎）を新設し、行動原理をまとめた文書を正式に配置しました。同時に、それまで第三層だった実務作業領域を第四層へ改番し、「哲学→戦略→行動原理→実務」の四層連結が完成しました。
行動原理として確立した7つの原理は、因果への忠誠・未来への奉仕・構造への還元・累積最適化・抽象への上昇・還源可能性・静寂への収束です。これらの上位に「因果に基づいて世界を理解し、未来の自分（とAI）を最重要ユーザーとして、構造を磨き続ける」という北極星の一文を置く形で文書化しました。
再編の実施にあたっては、影響範囲の調査を先行させ、変更対象を「生きた構造ファイル」に限定しました。過去の対話ログ・週次進捗ログ等の履歴ファイルは史実として保全し、フルパスのリンクが参照先不明になることは既知の脆弱性として許容する判断としました。フォルダの物理的な改番はスクリプトで実施し、バックアップを退避した上で実行しています。
再編後の取りこぼし点検として、説明文中に旧階層番号の記述が残存していた箇所をシステム全体で横断検索し、生きた構造の記述はすべて修正・史実記述はすべて保全と分類して対応しました。哲学文書についても、行動原理層への接続文を追加し、七層四連結の相互リンクを双方向化しています。これら一連の再編の経緯を記録した対話ログを複数の視点から新規作成し、知識管理システムに格納しました。
グループ連結システム変換の月次対応
あるグループ会社の月次連結処理について、今週は財務データ変換ツールのバッチ実行と不具合修正を実施しました。
バッチ実行では複数のグループ子会社について変換を試みた結果、一部でエラーが発生しました。エラーの原因は2種類に分類されました。一方は前月ファイルの不在によるもので、担当者によるファイル名の修正後に再実行することで解消できることを確認しました。もう一方はある子会社について、資産合計の照合値に差異が生じるというものでした。
差異の原因調査では、変換ツールの照合ロジックが「資産の部合計」との突合ではなく「負債＋純資産の再集計」との突合で設計されていることを実走査で確認しました。差異の発生源として、負債科目の1行（預り金）がコンフィグのマッピング設定に存在しないために変換処理でスキップされ、照合値に含まれないことが特定されました。前月の出力ファイルには同科目が既に存在していたことも確認しており、直接の原因はコンフィグの設定漏れであると結論づけました。
Phase3の修正では、コンフィグに1行を追加し再変換を実施しました。5項目の照合チェックが全て差異ゼロとなり、対象のグループ子会社の変換出力が完成しました。修正はコンフィグ1ファイルへの1行追加のみで、バックアップを退避した上で実施し、変更前後の差分も確認しています。この一連の調査・修正・検証の記録を対話ログとして知識管理システムに格納しました。
マネタイズ商品基盤の構築
今週は、Altinaflyのマネタイズ事業の土台となる商品管理リポジトリの初期化と、第一弾商品の整備を進めました。
まず、商品の実体ファイル（ファイル本体・README・product.yaml）を格納する実体側フォルダと、商品の一覧表・個別カタログを格納するカタログ側フォルダを、Altinaflyの知識管理システムの設計原則に従って分離して構築しました。実体側はナレッジ基盤の外部（業務ドライブ）に、カタログ側は行動原理層の配下に配置する設計です。商品のメタ情報はproduct.yamlを唯一の真実（Single Source of Truth）とし、カタログMarkdownファイルはスクリプトで自動生成する仕組みを実装しました。これにより、商品情報を手動で二重管理する必要がなくなりました。
第一弾商品として、チャット引継ぎプロンプトのキットをready状態まで整備しました。プロンプト本文・README・サンプル2点（Before会話とAfter引継ぎ書の対）を含むキット構成で、価格・ライセンス・免責事項も設定しています。product.yamlのステータスをreadyに更新し、カタログ側との整合も確認しました。サンプルのAfter引継ぎ書については、文章整合性の検査（発言の分断・順序入替・断片割り込みのゼロ確認）も実施しています。
もう1点の商品候補（請求書自動生成セット）についてはスキャフォルドのみで本体実装は未着手です。商品候補を幅広く台帳化するアイデア台帳を新設し、各候補について評価スコア・商品化前提（機密除去の要否）・実体確度の3軸で整理しました。台帳はスクリプトで初期生成し、以後は追加のみの運用としています。
また、フォルダ命名基準として「番号プレフィックスは第一階層のみに付ける（例外なし）」というルールを明文化し、システム定義文書に追記しました。第二階層以下のフォルダへの番号付与は、付番し直しコストとパス参照ノイズが便益を上回るという判断に基づく恒久ルールです。
会計システム導入の検討と決定
Altinafly自身の会計管理について、今週は会計システムの選定と導入方針を決定しました。
当初は自社で会計処理システムを開発する方針でしたが、検討の結果、既存のクラウド会計サービスを導入する方向に転換しました。判断の根拠として、自社開発の真の難所は会計ロジックそのものではなく、カードや口座明細の安定取得層の構築・保守にあること、および決算・法人税申告・電帳法追従といった制度対応コストを年数万円のSaaSで外部化できることが整理されました。これはナレッジ基盤整備における「累積最適化」の考え方と整合する判断です。
選定したサービスについては、一人法人向けプランを採用し、役員報酬の計算・年末調整・決算書作成に対応できることを確認しました。法人口座との自動連携については、フリー支店の新規開設が必要であることも判明し、既存の通常支店口座とは別に申し込む方針としました。クレジットカードとの即時同期による記帳自動化、および会計APIを活用したデータの自社ナレッジ基盤への引き出しについても方針を整理しました。
導入のフェーズ設計として、サービス契約→フリー支店開設申込→同期開始→カード申込の順序と、社会保険手続きとは独立して並行着手できることを確認し、次回着手の起点として記録しています。
おわりに
2026年6月11日〜6月18日の一週間は、法人設立後手続き・連結会計レビュー・予実管理・購買ワークフロー・ナレッジ基盤再設計・商品基盤構築・会計システム導入と、多領域にわたる作業が並行して進みました。それぞれのトピックにおいて、実走査による事実確認・承認ゲートの遵守・引継ぎ文書の整備という一貫した進め方を維持しています。引き続き、各案件の次工程を着実に進めてまいります。
