GitHubを更新しただけでは、社員が最新版を使えるとは限らない
樋門AIエージェントの共通版を社員の手元へ取り込む際、管理対象外の既存ファイル23件で検査が止まりました。ファイルを保全した検査、自動更新の模擬試験、本人アカウントでのメール受信確認と、運用に残る課題を記録します。
ここ数か月、私がAIと仕事をする中で整理してきた判断や手順を、社員にも使える形へ移しています。一人の仕事で得た蓄積を会社全体の資産にし、社員がそれぞれ同じ説明や指導を繰り返す手間を減らしたいと考えています。
前回は、樋門AIエージェントの更新をGitHubへ送る際、承認の確認で作業が止まった経緯を書きました。今回は、共通版を更新した後、その内容を社員の手元へ届けるところで苦労した話です。
配筋の知識を整理して共通版に反映し、社員の環境へ取り込む。その一連の作業を進める中で、手元にある既存ファイルをどう残すか、どこで検査するか、更新をどこまで自動で進めるかを、一つずつ考えることになりました。
配筋の蓄積を、社員が使う知識へ移す
私がAIと仕事を進めてきた中には、資料を示し、判断の理由を説明し、結果を見て直してきたやり取りがあります。社員へ共有する際には、そうした蓄積を、別の人が使っても判断の前提をたどれる形に整理する必要があります。
社員と使い始めて見えてきた不足については、これまでの記事でも触れました。今回改めて見たのは、私とのやり取りに残っていた判断や前提を、共通の知識へ移し切れていなかった部分です。共有用に整理する私の側の作業にも不足があり、配筋の情報を確かめ直しました。
今回の対象とした全鉄筋について、判断のロジックを一通り照合しています。ここで確認した範囲を土台に、社員が使う共通版へ内容を戻しました。今後も、実務で条件の違いや説明の不足が見つかれば、その都度補正していくつもりです。
照合を終えた範囲と、今後の使用を通じて確かめる範囲は分けて考えています。AIの出力も、資料や条件、図面・数量との整合を見て判断します。共有のための整理は私の側の課題として進め、AIがどの情報を根拠に、どこまで適切に扱えるかも確かめていきます。
過去に私が説明した内容を社員がまた一から教える負担は、できるだけ減らしたい。その上で、社員が実際に使う中で気づくことを、次の改善につなげたいと考えています。
共通版を更新した後に、社員側の取込みがある
GitHubは、共有するファイルと変更履歴を管理する場所です。今回は、見直した内容をそこにある共通版へ反映しました。
ただ、社員が仕事に使うファイルは、それぞれの手元にあります。共通版の更新に続いて、社員側でも新しい内容を取り込む作業が必要です。
今回は、社員の環境で手動の取込みを進めました。ここで確認できたのは、その時点の更新を手元へ取り込むところまでです。次回以降も更新を届ける方法は、これから運用として整えていく段階にあります。
社内のひな形やチェックリストでも、共有フォルダに新しいものを置いた後、各自が使うものを更新して初めて修正が次の仕事に生きます。今回も同じで、GitHubへの反映を確認した後に、使う側の状態を見る作業が残っていました。
共通版へ反映したことと、社員が使う手元の版を更新できたことは、別々に確かめる必要がありました。
検査を進める前に、既存ファイルを保全する
社員側の環境を確認したところ、Gitの管理対象外になっている既存ファイルが23件あり、そこで検査が止まりました。Gitは、ファイルの変更履歴を管理する仕組みです。
これらは、照合作業に伴う検査用プログラムや中間データなどの出力です。Gitでは、共有するファイルとは別に、管理対象から外すファイルを指定できます。共有対象かどうかと、そのファイルを残す必要があるかは、別に考えることになります。
今回は、元のファイルを残したまま、別に用意したコピーで検査を進めました。そのコピーでは、対象の検査項目を通過しました。
この結果で確かめられたのは、分けて用意した環境での動作です。社員が使っている元の環境については、残したファイルや作業中の状態も含めて、別に見る必要があります。
更新する側から見ると、手元のファイルが少ない方が扱いやすいかもしれません。社員が使う環境を扱う以上、すでにあるファイルをどう保全するかも、更新の手順に含めたいと思います。
検査が止まったことで、何を更新し、何を残すかを確認する機会になりました。止まった理由を見て、既存ファイルを保ち、検査する場所を分ける。今回は、その手順を踏んで進めました。
自動更新は、独立した試験環境で確かめた
毎回手動で取り込むなら、更新を忘れたり、人によって使う版が違ったりする可能性があります。その手間を減らせないかと考え、自動で取り込む処理も試しました。
試したのは、私のPC上に用意した独立した作業環境です。実際の共有先とのやり取りを模した環境で、複数の条件を確かめました。この試験では、自動で更新を取り込み、模擬の既存ファイルを残せることを確認しています。
実際のGitHubに対しては、共有先の情報を読み取る操作が成功しました。ここまでの結果は、模擬環境での動作確認と、実際の共有先への接続確認です。社員の環境で自動更新を使う検証は、これから進めることになります。
処理が動いた後にも、日々の運用で見ることがあります。いつ更新を確認するか。作業中に確認が入っても支障がないか。途中で止まったとき、社員に何を伝えるか。時間やAIの使用量への影響も含めて、実際の使い方に合わせて確かめたいと思います。
固定したプロンプトで、手動で始める方法もある
自動更新を試す一方で、手動で進める方法も選択肢に入れています。選ぶ基準は、修正した内容を社員が使え、手元のファイルを保全しながら無理なく続けられることです。
例えば、更新時にAIへ渡す依頼文であるプロンプトを決めておき、社員が必要なタイミングで依頼する方法が考えられます。現在の版と新しい版を確かめる。作業中の変更や、保全するファイルがあるかを見る。取り込める状態か、人に確認することがあるかを知らせる。こうした一連の確認を、決まった頼み方で始める形です。
この方法も、これから具体化する案です。毎回共通して確かめることをまとめつつ、状況に応じて止め、人へ相談する判断も組み込みたいと考えています。
自動で進む範囲が広ければ、その分、停止する条件や例外への対応が重要になります。手動で始める方法では、誰がいつ確認するかを決めることになります。それぞれの負担を見ながら、社員が続けやすい方法を選びたいと思います。
前回扱った操作の承認と、今回の更新や検査、それから配筋内容の技術的な確認は、それぞれ役割が違います。更新できたことを確かめた後も、個々の案件では、根拠や適用条件、図面・計算・数量の整合を見て判断します。その確認に使う情報を、社員の手元へ届けるところまで整えたいのです。
改善を戻すための通知も、実際に試した
更新を社員へ届けることと並んで、使う中で見つかった疑問や工夫を、会社の共通の知識へ戻す流れも整えたいと考えています。
このための連絡経路は、一部を実際に試しています。2026年10月28日には、私自身のGitHubアカウントで変更提案であるプルリクエストを作り、共通版へ取り込んだ後にコメントを付けました。その通知が、会社の私宛てのメールに実際に届くところまで確認できています。
ここで試したのは、私自身のアカウントからの操作と受信です。社員のアカウントから同じ流れで届くか、日々の業務の中で継続して使えるかは、次に確かめることになります。
連絡が届いた後には、内容を確認し、共通版へ採用するかを判断する作業があります。説明が足りないと感じたところ、案件の条件に合わせて判断したところ、確認しやすいように工夫した手順。そうした内容を上げてもらい、根拠や他の案件へ使える範囲を確かめて、全員へ返したいと考えています。
社員が日々残せる程度の負担で、別の人も判断の経緯を理解できる情報をどう集めるか。誰が確認し、採用した内容をどう知らせるか。通知の実受信まで確かめた結果を土台に、社員の参加と確認・還元の運用を具体化していきたいと思います。
今回は、配筋の情報を整理し、共通版を更新して、社員の手元へ取り込むところまで進みました。その途中には、既存ファイルを保全し、検査する場所を分け、次の更新方法を試す作業がありました。改善を戻すための通知経路も、本人アカウントでの試験まで進んでいます。
同じように社内でAIを使い始めた会社でも、共有先を用意した後に、似た課題が出てくるかもしれません。各自がどの版を使っているか。更新時に既存のファイルを残せるか。不足に気づいたとき、誰に戻してどう確認するか。このあたりを実際の仕事に沿って確かめることが、運用を整える手掛かりになると思います。
私が蓄積してきた内容を社員へ届け、社員が使って得た経験を次の改善へ返していく。今回のような一つずつの作業を通じて、会社で使いながら育てる形にしていきたいと思います。