AIを使ってiPhoneアプリを開発しながら、Webライターの仕事も続けています。開発するアプリが増えるにつれて、GitHubのIssue管理やアプリの公開状況、売上、マーケティングの実績など、確認する情報も増えてきました。
そこで作ったのが、個人事業の管理システム「YAMATO」です。
MacとDebianでデータを収集し、AIエージェントには調査や分析を担当させています。集まった情報はYAMATOのダッシュボードへ送り、事業の状況を一つの画面で確認する構成です。
ところが、運用を進めるうちに予想外の仕事が増えました。
AIから完了報告が届くたびにGitHubを開き、処理の結果を調べます。ダッシュボードに表示された数値も、取得日時や対象期間を確認しなければ安心して使えません。
AIへ任せられる仕事は確実に増えました。その一方で、AIの仕事を確認するために自分が動く場面も多くなったのです。
今回はYAMATOの運用で実際に経験した三つの問題を取り上げ、AIエージェントの完了判定と状態管理について考えてみます。
1人で事業を運営するために、AIの組織を作った
私はWebライターとして企業向けの記事を書く一方、個人でiOSアプリを開発しています。
アプリの開発では、ソースコードの管理からTestFlightへの配信、App Storeの審査対応まで、さまざまな仕事が発生します。公開後には利用状況や売上の確認も必要です。
Webライターの仕事にも案件管理や納品、売上管理があります。これらを一人で処理していると、実際に手を動かす仕事と同じくらい、各サービスの状況確認に手間がかかるようになりました。
そこで考えたのが、AIエージェントを利用した事業運営の自動化です。
GitHubをソースコードとIssueの管理先にして、MacやDebianにはデータ収集や実行処理を担当させます。AIエージェントが行った調査や分析もYAMATOへ送り、私はダッシュボードを見て次の仕事を判断する。そんな構成を目指しました。
YAMATOの役割分担
図1：YAMATOに情報を集約する構成の概念図。各システムの役割を表しており、実際の通信経路をすべて示したものではありません。
役割を分けることで、複数の仕事を並行して進められるようになりました。AIが担当できる調査も増えています。
ただ、ここで一つ見落としていたことがあります。
AIから受け取った報告を、何を根拠に完了と判断するのか。
この基準が十分に決まっていなかったのです。
GitHubのIssueをCloseしても、画面には残っていた
問題を実感したのは、YAMATOのIssue管理機能を使っていたときでした。
GitHubのIssueを整理するため、YAMATOにはCloseの可否を判断する画面を用意しています。作業内容を確認し、Closeボタンを押してIssueを閉じるための仕組みです。
ところが、ボタンを押したあとも対象のカードが画面に残ることがありました。
最初は画面の更新が遅れているのかと思いました。しかし、原因を調べるには複数の処理を確認する必要があります。
Closeボタンの操作は送信されたのでしょうか。GitHubへの更新要求は成功しているでしょうか。GitHub側でIssueがclosedになっていても、YAMATOが古い情報を表示している可能性があります。
そこで、完了までに確認する工程を整理しました。
Issue Closeで確認すべき5つの工程
図2：Issue Closeの完了判定として目指す処理フロー。すべての工程が本番環境に実装済みという意味ではありません。
例えば、GitHub側でIssueがすでにclosedになっている場合、調べるべき場所はYAMATO側の同期処理や表示処理に絞られます。
一方、GitHub側でIssueがopenのままなら、APIの呼び出しや認証、エラー処理を確認する必要があります。
ここで困るのが、AIから返される完了報告です。
「処理しました」という報告だけでは、どの工程まで成功したか判断できません。実際の状態を確かめるため、結局は自分でGitHubを開くことになります。
この経験から、完了報告には処理の結果と更新先の状態を含める必要があると考えました。
なお、今回発生したClose操作の不具合について、すべての実行ログを照合できているわけではありません。図2は、同じ問題を調査するために整理した確認手順です。
データの取得に成功しても、ダッシュボードが更新されない
売上やアプリの利用状況を集計するときにも、似た問題が起きました。
YAMATOではApp Store ConnectやTelemetryDeck、アフィリエイトサービスなどから情報を収集しています。
AIが外部サービスへアクセスして数値を取得できても、その結果をYAMATOの画面へ反映するには、データの送信と受信側での処理が必要です。
例えば、AIから送られてきたデータが受信側の想定する形式と異なっていれば、画面の数値は更新されません。
AIの報告には「取得成功」と書かれていても、ダッシュボードには古い数字が残っている。そんな状況が発生しました。
そこで、取得結果を観測レコードとして扱う方針にしました。
観測レコードには、取得元のサービスや対象期間、取得日時、取得状態、実際に取得した数値などを記録します。
これにより、どの期間の数字をいつ取得したのか、今回の取得処理が成功しているかを区別できます。
「0」と「未取得」を同じ数字として扱わない
特に気を付けているのが、データを取得できなかった場合の扱いです。
例えばApp Store Connectで再認証が必要になり、売上データを取得できない場合があります。
このとき売上を0として保存すると、実際に売上がなかった場合との区別がつかなくなります。
そこで、取得に失敗した場合は直前の正常な取得値を保持し、今回の取得状態を別に記録する方針にしました。
図3：正常取得と取得失敗に応じたデータの扱い。
例えば、2026年10月1日から30日までのアプリユニットが246だったとします。
その後、認証エラーによって最新の数値を取得できなくなっても、前回の246ユニットという記録は保持します。ただし、その数字を11月の実績として表示してはいけません。
画面には対象期間を明示し、最新の取得状態が認証待ちであることも伝えます。
月が替わった直後にも同じ考え方が役立ちます。前月の集計値と当月の集計値を区別して扱えば、新しいデータが届いていないだけなのか、実際に売上が0なのかを判断しやすくなります。
数字だけを見ると、こうした違いは分かりません。取得日時と対象期間を一緒に管理する理由はここにあります。
AIの仕事を増やした結果、管理画面まで増えてしまった
YAMATOを作り始めた頃は、AIの役割を増やすことで作業を効率化しようと考えていました。
調査を担当するAI、マーケティングを担当するAI、GitHubの状態を確認する処理、MacとDebianの稼働監視。それぞれに担当を持たせる構成です。
実際に運用すると、各担当から届く報告を確認する仕事が増えました。
ある画面では作業が完了しているのに、別の画面には古い情報が残っています。同じ問題が複数の場所に表示されれば、それぞれを確認する必要も出てきます。
そこで2026年10月末から、普段確認する画面をYAMATOに集約する方針へ変更しました。
GitHubはIssueとソースコードの管理先として維持します。MacやDebianには収集と実行を担当させ、AIエージェントが行った分析もYAMATOへ送ります。
私はまずYAMATOを開き、詳細を調べる必要がある場合に元のシステムを確認する運用を目指しています。
ただ、確認先を一つにまとめても、データが古ければ正しい判断はできません。
そのため、YAMATOに集める情報には取得元や対象日時を残します。必要に応じて元の情報を追跡できるようにしておくことも欠かせません。
AIの仕事は、どの時点で完了と判断するべきか
ここまでの経験から、作業の完了を三つの段階に分けて考えるようになりました。
1. 実行の完了
最初に確認するのは、依頼した処理が実行されたかどうかです。
例えばGitHub APIへの更新要求に対して正常な応答が返ってきた場合、APIの呼び出しは成功したと判断できます。
この結果は実行ログとして記録します。
2. 更新先の状態確認
次に、更新先から最新の情報を取得します。
GitHub IssueのCloseであれば、対象のIssueがclosedになっているかを確認する工程です。
ここまで確認できれば、AIから受け取った報告と実際の状態を照合できます。
3. ダッシュボードへの反映
最後に、YAMATOの画面に結果が反映されているか確認します。
GitHubではclosedになったIssueが画面に残っている場合、同期処理や表示処理の調査が必要になります。
こうして工程を分けておけば、問題が発生した場所を絞り込みやすくなります。
また、再実行する際にも役立ちます。
すでにGitHub側でIssueがclosedになっていれば、その状態を読み取ったうえで後続の処理を進められます。処理によっては、結果が不明なまま再実行すると重複による問題が発生する可能性もあります。
AIエージェントに仕事を任せる際には、正常終了をどう判断するかに加えて、失敗後の再実行をどう扱うかも考えておきたいところです。
これから、どこまで確認作業を減らせるか
YAMATOは現在も改修を続けています。
2026年10月末から管理画面の整理と役割分担の見直しを進め、普段の確認先をYAMATOに集める方針は固まりました。
今後は実行ログと更新先の状態を照合し、正常終了した仕事を自動的に記録する範囲を広げたいと考えています。
認証が必要になった場合や処理が失敗した場合には、その理由と次に必要な操作をYAMATOへ表示します。人間が確認するべき仕事を把握しやすくするためです。
現時点では、確認作業が何時間減ったかという効果までは測定できていません。この点についても、実際の運用結果を見ながら検証していく予定です。
AIエージェントに任せられる仕事が増えると、次は各処理の結果を確認する仕組みが必要になります。
私はYAMATOの運用を通じて、そのことを実感しました。
これからAIエージェントによる自動化を進める人は、実行処理を作る段階で、完了判定と失敗時の状態管理も考えておくと、運用開始後の調査に役立つと思います。