waiting_us
櫻井 様 いつもお世話になっております。 今週の技術顧問の日程ですが、 第１希望：7/29(水)16:30以降 第２希望：7/31(金)12:00〜15:00 で調整のほどよろしくお願いいたします。 また、先ほど別途メールを送らせていただいております。 並行稼働を開始するために最低限ご対応いただきたい内容となっておりますので、お忙しいところ恐縮ですがよろしくお願いいたします。 2026年7月24日(金) 14:58 櫻井美奈 <m-sakurai@ai-path.jp>: > 桃谷順天館 > 溝手様 > > お世話になっております。 > AI-Path CEO室の櫻井美奈です。 > > 先日はお時間をいただきありがとうございました。 > 大変遅くなりましたが > 末尾に当日の議事メモを共有させていただきます。 > > また次回について、最終週の候補日程を記載させていただきます。 > > 【候補日程】 > ・7/27(月)15:30〜17:00 > ・7/29(水)16:30以降 > ・7/30(木)15:00〜17:30 > ・7/31(金)10:30まで/12:00〜15:00 > > なお、恐れ入りますが現在複数日程調整中につき > 可能でしたらご都合のつく日時をいくつかご教示いただけますと幸いです。 > > 何卒よろしくお願いいたします。 > > ---以下議事メモ--- > 基本情報 > • 会議名: 桃谷順天館 製造指図システム 開発定例MTG > • 日時: 2026-07-15 16:30〜17:30 > • 場所: オンライン（画面共有で実施） > • 出席者: > • 相手方（桃谷順天館） > • 溝手章子様 > • 小松原 雅彦様 > • 自社（AI-Path） > • 櫻井 文雄（CEO） > • 櫻井 美奈 > • 議事録作成者: 櫻井 美奈 > 会議の目的 > > 製造指図システムの開発運用ルール（ブランチ/PR/DB変更）を溝手章子様と共有したうえで、承認フローの設計・製造指図画面の仕様・管理番号の裁番ルールなど現場要件をすり合わせ、実装方針を確定する。 > 議題 > 議題1: 開発運用ルール（ブランチ/PR/DB変更の扱い） > *議論の軌跡:* > • 溝手章子様: > 前回教わったので触っていこうと思うが、「一旦あそこでは結構…データベースをがらっと変えちゃうんじゃないか」という懸念があるところも、まず自分で触ってみて、あとは櫻井さん側で判断してもらう形でどんどん進めても問題ないか？ > 採用されないものが出てくる可能性はあると思う。 > • 櫻井文雄: > それで行くと少し違っていて、最初はデータベースをいじらないものに留めてもらった方がいい。「データベースいじってしまうと、もう後戻りできない」。今は開発環境が1面しかなく、本番環境用のものはまだ用意していない。データベースが一つしかないので、いじって万一壊れたらリカバリーができない。「なんでデータベースをいじるのはNGです」。 > • 溝手章子様: NGなんですね、わかりました。 > • 櫻井文雄: > 画面を変えるのは仕組みで言うと別。今この前やってもらったものがプルリクエストという形で来る。サイドバーを非表示にした、出荷日の表示をこうした、といった内容はデータベースをいじっていないので問題ない。 > • 櫻井文雄: > リモート上のGitHubでは、メインに上がっている内容が本番で動くもの。ブランチを切って機能単位で作業し、「このブランチは溝手さんが好きにやっていいやつ」という管理ができる。メインは本番コードなのでいじってはいけない。今回AWS > Amplifyを入れているため「メインのコードをマージすると勝手にビルドが走って本番環境に出てしまう」。だからメインへ直接マージせず、まずPRを上げてほしい。PRを上げるとAIが中身を確認してレビューし、「表示の順を変えるやつだけ」と妥当性を判断してくれる。 > • 櫻井文雄: > すでにあるDB項目を非表示にするのは画面表示だけの話で問題ない。だが項目追加やテキスト項目を数値型に変える（データ型変更）と、既存値と整合性が取れない・他の参照箇所との依存関係が崩れる恐れがあるので、変更の前後で影響調査をし、リグレッションテストを裏で走らせる必要がある。並行稼働で溝手さん側がデータを入れて業務を回している最中なので、DB系は一緒にいる場でやるのがいい。 > • 溝手章子様: > 明日また自分で何かやってみようと思ったとき、最新版を一旦入れるとメインブランチになっているので、そこからまたブランチを切って作業し出すというステップを踏めばいいか？ > • 櫻井文雄: > 安全のためにも、今作ってある溝手さんのブランチだけを触っておけばメインを見なくてよい。作業ブランチを溝手さんの名前にして切り替え、メインの最新コードを付与すればメインの最新状況がそのブランチに同期される。「自分のブランチをどんだけ汚そうが、データベースさえ直接いじらなければ大丈夫」。データベースのMCP設定は終わっていてテーブル構造を変えられてしまうが、自分でマージできるようになるまではDBはいじらないでほしい。 > • 溝手章子様: わかりました。 > *論点:* > • 開発環境が1面のみでDB破損時のリカバリーができない > • メインへのマージがAWS Amplifyで即本番デプロイに繋がる > • DB変更は影響調査・リグレッションテストを要し、並行稼働中はリスクが高い > *決定事項:* > • 当面データベースは直接変更せず、DB非依存の画面変更のみを各自ブランチ上で行いPRを上げる > • DB変更は櫻井文雄と同席の場でのみ実施する > • 各自は自分のブランチ上で作業しメインへ直接マージしない。PRを上げAIレビュー後に櫻井文雄がマージする > • 決定に至る背景: > 開発環境が1面のみで本番/平行環境が未整備のため、DBを壊すとリカバリーができず、メインへのマージはAmplifyで即本番反映されるため。 > 議題2: Excel風編集ライブラリの差し替えと Windows/Mac 並行開発 > *議論の軌跡:* > • 櫻井文雄: > このハンソンテーブルというライブラリは開発環境なら使っていいが、公開環境だとお金がかかることが発覚した。自前でライブラリを作ったので、タイブルという新しい仕組みへ差し替える作業が発生する。 > • 溝手章子様: すみません、この間の「編集のなんとかやってる」という仕組みですか？ > • 櫻井文雄: > 違います。Excelみたいに編集する仕組みで、小松原さんに使ってもらう製造指図書のところで使っている。片方はもう自前のタイブルに差し替えて動くよう直したが、もう片方はまだ差し替えが終わっていない。ハンソンテーブルは使い勝手はいいが曲者で、最近いろんなプロジェクトで差し替えに追われている。本番リリース時に「万が一お金を払えと言われたら大変で、16万ぐらいかかる」ので消しておきたい。 > • 溝手章子様: よろしくお願いします。 > • 櫻井文雄: > あと、Windows環境とMac環境での並行開発は自分もしたことがなく、コードが結構ぶつかる。今回のテールウィンド（Tailwind）の修正で、こちらで動くようにするとそちらが動かなくなる可能性があるので、動かなくなったら言ってほしい。両方で動く対策を考える必要がある。 > *論点:* > • ハンソンテーブルは公開/本番で課金（約16万円）が発生する可能性 > • 製造指図書側の差し替えが未完了 > • Windows/Mac 並行開発でコードが競合する > *決定事項:* > • Excel風編集ライブラリをハンソンテーブルから自前のタイブルへ差し替える > • 決定に至る背景: 公開/本番環境ではハンソンテーブル利用に約16万円の課金が発生するため。Windows/Mac競合は要対策として継続監視。 > 議題3: issue（タスク）管理の粒度と AI 自動起票 > *議論の軌跡:* > • 溝手章子様: （製品マスターへの項目移動タスクについて）これは自分で書いたのではなく、多分櫻井さんに書いていただいたものだと思う。 > • 櫻井文雄: > いや、自分は書いていない。これは前回の会議の議事録内容からAIで丸めて備忘録として起票したものが、自分の名前になっているだけ。「後で起票し忘れないよう、AIでパッと入れたやつ」。 > • 溝手章子様: 自分だとそこまでの文章は書けないので、確かに自動で入ったものだと思う。 > • 櫻井文雄: > 表側の人は表の項目名で書くが、これは裏側のテーブル名で書いてある。ただ内容が丸まっているので、なるべく丸めない方がいい。「ちゃんと検証を順番にやっていかないと、この部分だけは直っていたがここが直っていない、という漏れが起きがち」。削除が終わっているかというタスク単位ならクローズしやすいが、丸まっていると何が本当に残っているか分からなくなる。 > • 溝手章子様: そうですね、クローズしようと思って迷っているものがたくさんある。 > • 櫻井文雄: 何が本当に残っているかを見やすくするため、管理しやすい単位で > Issueずつ切った方がいい。会議の議事録をまとめて貼ったので丸まってしまった。AIで起票すると全部自分（櫻井）の名前になってしまう。漏れがあればチャットで突き返してほしい。 > *論点:* > • 議事録を一括で貼ったためタスクが丸まり、完了/未完の判別が困難 > • AI自動起票で担当者名が実装者（櫻井）になってしまう > *決定事項:* > • issue（タスク）は丸めず1単位ずつ細かく切って管理する > • 決定に至る背景: 丸まったタスクでは検証漏れやクローズ判断が難しいため。 > 議題4: 製品マスターへの項目移動（issue 0133） > *議論の軌跡:* > • 溝手章子様: > ECの中のデータのところを先にいじってほしい。製品マスターに、もともと支援マスターに付いていたカウント項目を移動してほしい。「20の0133」を先に処理してほしい。それができると、カウントがあるときの動作確認ができる。 > • 櫻井文雄: （番号を確認して）0133ですね。画面上にも出すということでしたか？ > • 溝手章子様: 画面上にも出してほしいです。 > • 櫻井文雄: > これは規模が大きすぎて、切り方がまとまりすぎている。一個の単位に分けてやらないとテストがこけたり意図しない結果になる。（項目追加・インポート/エクスポート対応まで実施し）直っている所と直っていない所があると思うので、後で確認して漏れがあればチャットで返してほしい。 > *論点:* > • タスク0133が複数対象を含み粒度が大きい > *決定事項:* > • 支援マスターのカウント項目を製品マスターへ移動し、画面上にも表示する（0133） > • 決定に至る背景: カウントがある場合の動作確認の前提になるため先行対応。タスクは1単位ずつに切り分けて実施する。 > 議題5: 承認フローの設計（順序性・代理承認・作成者≠承認者） > *議論の軌跡:* > • 溝手章子様: 今この形で出してもらっているが、作成・審査・承認のところが画面に出ていなくて、どういう操作になるのかと思って。 > • 櫻井文雄: > この前一緒にやったとき、承認履歴の仕組みがAIによって吹っ飛ばされ、違う形に書き換えられる事故が起きている。過去に「これでいきましょう」と見てもらったものがあるので、なぜ消されたか後で調査するが、一旦当時作っていたものを復旧中。 > • 溝手章子様: 操作としては、ログインしている人が承認を押したら名前と日付が自動で入るぐらいの機能です。 > • 櫻井文雄: > 申請は小松原さんがやる作業で、承認は品管の人しかできない（小松原さんは押せない）。ミスに気づいたら引き戻しができるが、引き戻しても承認履歴は消さないようにしていたはず。差し戻しの権限はあるが、スーパー管理者には差し戻し権限を付けていない。名前と日付は自動で入る。 > • 溝手章子様: 順番は審査→承認だった。実務上は承認も押した状態で回っていて、承認が普通は後にある。「結構実務がおかしいんです」。 > • 櫻井文雄: > つまり順序性を持たせられないのが悩みで、品管を通してから承認ではなく、作成と承認はこちらでやりつつ品管はパラで動いている、ということか。この承認は今、岡村さんや川村さんがやっている？ > • 溝手章子様: 製造現場の幹部職が承認する状態。 > • 櫻井文雄: では小松原さんが作って、究極は小松原さん自身が承認する？ > • 溝手章子様: 石井さんが承認する。 > • 櫻井文雄: 代理承認の話として、小松原さんが作成して時間がないから自分で承認せざるを得ない、でもダブルチェックしていない、と言われる可能性がある。 > • 溝手章子様: > システム上、代理承認を誰かができる状態にしておかないと、承認者2人がとも休んだとき承認できず翌日に飛ばすのかとなり、それも違う。代理承認は可能にしつつ、作成→依頼で品管に飛び、品管がOKしたら承認に飛ぶという流れがいい。 > • 櫻井文雄: > 作成者と承認者を一緒にするのはISO的にダブルチェックを引いていないことになりNG。承認者（石井さん）が不在のときに承認できる同格の人を設定し、作成者とは異なるが同格の誰かなら承認できるようにするのが現実的。品管承認と現場責任者承認は並行で動かすのが一つの方法。 > • 溝手章子様: 並行で動かす方でお願いしたいです。 > • 櫻井文雄: 承認は権限（ロール）で制御している。品質管理担当は伊沢さん・瀬国さんあたり、現場責任者は石井さん・黒石さん（生産革新責任者）。 > • 溝手章子様: > 部署異動はあったが二名いる状態は変わらない。代理という考え方より、生産革新責任者チームを複数人に付けておけば、いれば使えるし、いなくてもダブルできる扱いにできる。 > • 溝手章子様: 今は管理職が現場に多いので、そのメンバー4人を入れておけば全員いないことはない。 > • 櫻井文雄: では溝手さんが触れるので、製造革新責任者のところに複数人いれば、その人たちが承認できる形にすれば大丈夫。 > *論点:* > • 承認履歴の仕組みがAIの誤操作で消失し復旧中 > • 作成者=承認者はISO上ダブルチェック違反 > • 承認者不在時に承認が滞る > *決定事項:* > • 承認フローは作成者と承認者を別にし、品管承認と現場責任者承認は順序性を持たせず並行で動かす > • 代理承認を可能にし、生産革新責任者ロールを複数名（4名程度）に付与して不在でも回るようにする > • 承認操作はログイン者の名前と日付を自動記録し、スーパー管理者には差し戻し権限を付与せず承認履歴を消さない > • 消された承認履歴の仕組みは櫻井文雄が原因を調査し復旧する > • 決定に至る背景: 作成者=承認者はISO違反となり、承認者2名が同時不在だと承認が止まるため、同格ロールを複数付与して代理承認を可能にした。 > 議題6: 製造指図画面の初期値・編集可否 > *議論の軌跡:* > • 溝手章子様: 気になっているのが、今この時間のところ、9時から3時と出してもらっているやつ。初期値はもう入るようになっているか。 > • 櫻井文雄: 初期値は開いたとき確かに9時になっている。初期値は何にしたいか、ブランクでもいいが希望はあるか。 > • 溝手章子様: 初期値は9時10分がいいです。 > • 櫻井文雄: 了解です。 > • 溝手章子様: > 生産計画でワークで入れた内容が飛んできていて、時間差の自動計算で入りにくい順で入れてくれるが自分で変えられる。人数も状況によって変わるので変えられた方がいい。ラインも状況によっては使えないトラブルがあるので編集したい。人数も、普通は5人でやりたいが、人がいなくても出荷があるから3人でやらなければいけないことがあるので編集できるようにしたい。 > *論点:* > • 時間初期値の設定値 > • ライン・人数のイレギュラー変更への対応 > *決定事項:* > • 製造指図の時間初期値を9時10分に設定する > • 製造指図画面でライン・人数を編集可能にする > • 決定に至る背景: 人員不足やライン不調などイレギュラー運用が発生するため。 > 議題7: 管理番号の裁番ルール > *議論の軌跡:* > • 溝手章子様: 管理番号が今、コピーするとかぶってしまう。かぶらないよう、ボタンを押したら全部ばらけるようにできるか。 > • 櫻井文雄: 今は自動で取って入れているが、コピーすると同じものになる。どういうルールで採番し直したらいいか、管理番号の採番ルールをどうするか。 > • 溝手章子様: 今やっているのは26071501のように、上から順番に1・2・3…としている。被らなければOKという状態。 > • 櫻井文雄: 並び替えたとき、同じ日の中で番号が常に変わる方がいいか、変わらない方がいいか。 > • 溝手章子様: > 変わらなくていいです。上から確実に順番になっていないといけないルールはないので、ユニークさえなっていればいい。アルファベットを使うと入力しづらくなるので、日付に「02」「03」のような形でぱっと見て今日の日付の何番か分かる感覚で使っている。 > • 櫻井文雄: これは100以下で収まりますか。 > • 溝手章子様: 収まります。100を超えることはない。 > • 櫻井文雄: わかりました。管理番号の裁番体系を見直します。 > *論点:* > • コピー時に管理番号が重複する > • 並び替え時の挙動と桁数（100件未満） > *決定事項:* > • 管理番号は日付(YYMMDD)+連番でその日ユニークとする裁番ルールにする > • 並び替えで番号は変わらなくてよい（ユニークであれば順序の連続性は不要） > • 決定に至る背景: 現行運用が日付+連番で1日100件未満に収まり、被らなければよいという要件のため。 > 議題8: ロット単位キーと外部記録書システム（エクシーゲート）連携 > *議論の軌跡:* > • 溝手章子様: 押印ピッキングにも管理番号があるが、そこもかぶらないようにしないと使えなくなる。 > • 櫻井文雄: 製造指図系と応援ピッキングはテーブルが全部別々だが、テーブル横断で管理番号を一律に振るということか。 > • 溝手章子様: > もし無理なら、ピッキングの方を形を変えて被らないようにしたい。この用途も99番くらいまでで収まる（5年ほど運用して超えたことがない）。 > • 溝手章子様: もう一つ、管理番号が一行につき一個欲しいものと、一行の中にロットが2個あったらロットごとにまた管理番号が欲しいという要件がある。 > • 櫻井文雄: ロットごとに管理番号が欲しい場合、（管理番号欄）には何を出すのか。用途が分からないとデータ構造的に破綻してしまう。 > • 溝手章子様: > 記録を取っている。エクシーゲート（記録書のシステム）で製品記号やロットを入れるが、自分たちで入れると間違えるリスクがあるので、製造指図のデータを加工して製品キーと1対1で渡している。 > • 櫻井文雄: > 大体理解した。それなら（別の管理番号は）いらない。管理番号とロット番号の組み合わせでユニークキーになるから。外部システム連携のためのユニークキーを作りたいということですね。 > • 溝手章子様: > 外部連携のためだが、呼び出すときに管理番号を入れて呼び出すので、複雑になると作業者の入力が変わるのを気にしている。管理番号だけ入れたら製品記号もロットも全部参照されて出てくる。 > • 櫻井文雄: 管理番号とロットは1対1になるのか。ロットがそもそもユニークではないのか。 > • 溝手章子様: ロットは他の製造管理番号にも紐づく時がある。同じロットを今日も明日も作ったりするので。 > • 櫻井文雄: > それなら、管理番号とロットの組み合わせで行くしかない。管理番号は同じ日の中で必ずユニークなので、その日のどのロットの分かでユニークキーになる。入力の手間を変えるより、そうしないと必ずどこかで違うものと紐づける事故が起こる。 > • 溝手章子様: 皆さんを説得します。ロット番号は入力が大変という話が起こるだろうなと思ったので。 > • 櫻井文雄: > ロット管理番号の新しいテーブルを作ろう。管理番号+ロットの組み合わせで、その日ユニークになるキーを他の数字で振っていって、ユニークキー一覧を持つ。名前は「エクシーゲート用のキー」など分かりやすい名前でよい。それを印字のタイミングで別紙に出す形で、作業者が入力して呼び出せるようにする。 > • 溝手章子様: > 名前は考えます。今かなり雑に、一行に一個とロットごとに欲しいものをぐちゃぐちゃに無理やり使っているので、システム上はそういう状態ができないのは理解している。 > • 溝手章子様: > （画面共有で説明）製造指図データをCSVで自動取り込みし、最終検査表などで管理番号を入れると製品記号・計画番号が反映され、検査記録を入力する。記録書は必ずロットごとに作るのが会社ルールなので、ロットごとの管理番号を使っている。 > • 櫻井文雄: > 管理番号とは別の名前にしないと混乱する。ほぼ同じ情報（製品記号・装置・作業内容等）を、ロット番号だけ違う行としてCSVで吐き出せばいいということですね。時間の都合でここは持ち帰って考えます。 > *論点:* > • テーブル横断（製造指図系/ピッキング系）での管理番号重複回避 > • 一行1個の管理番号とロット単位の管理番号が混在し破綻している > • 外部記録書システム連携時の作業者入力の手間 > *決定事項:* > • > ロット単位で必要なキーは管理番号と別名の新テーブル/キー（エクシーゲート連携用キー）として分離し、管理番号+ロット番号の組み合わせでユニークキーを作る > • 該当キーは印刷時に別紙で出し、作業者が入力して呼び出せるようにする > • 決定に至る背景: > 記録書がロットごとに必要でロットは他の管理番号にも紐づくため、管理番号単独では一意にできず、組み合わせキーでの分離が必要なため。正式名称は溝手章子様が検討し現場に説明・説得する。 > 検討中・保留事項 > • ロット単位キー（エクシーゲート連携用キー）の正式名称は未定（「ロット管理番号」「エクシーゲート用キー」等の案のみ） > • 管理番号+ロットの組み合わせ運用について現場の合意形成（溝手章子様が持ち帰り説得） > • Windows/Mac 並行開発の競合対策（片側修正で他方が動かなくなる可能性への恒久対応） > • 押印パッキング（応援ピッキング）系テーブルの管理番号重複回避方式 > • 外部記録書システム名「エクシーゲート／エクシーゲリオ」の正式表記・製品名（要確認） > 次回会議予定 > • 未定（溝手章子様は翌日以降ブランチ上で作業を進める旨に言及。定例日程は本会議では確定せず） > 会議のまとめ > 本会議は桃谷順天館の製造指図システムについて、開発運用ルールと現場要件をすり合わせるものだった。まず、データベースを壊すとリカバリーできず、メインへのマージがAWS > Amplifyで即本番反映される構造を踏まえ、溝手章子様は当面DB非依存の画面変更のみを自分のブランチ上で行いPRを上げ、DB変更とマージは櫻井文雄が担う体制を確認した。実装面では、課金が発生するハンソンテーブルを自前のタイブルへ差し替える方針とし、丸まったタスクは1単位ずつ切って管理することで合意した。現場要件では、ISO上のダブルチェックを満たすため作成者と承認者を分け、品管承認と現場責任者承認を並行で動かし、生産革新責任者を複数名に付与して代理承認を可能にする設計を固めた。製造指図画面は時間初期値を9時10分にし、ライン・人数を編集可能にする。管理番号は日付+連番でその日ユニークとし、記録書システム連携で必要なロット単位のキーは管理番号+ロット番号の組み合わせで別キーとして分離する方針とした。名称確定と現場合意、承認履歴復旧が次の宿題となる。 > 決定事項 > • 当面データベースは直接変更せず、DBに依存しない画面変更のみを各自のブランチ上で行いPRを上げる。DB変更は櫻井文雄と同席の場でのみ実施する。 > • 各自は自分のブランチ（溝手ブランチ）上で作業し、メインへ直接マージしない。作業はPRを上げAIレビュー後に櫻井文雄がマージする。 > • Excel風編集ライブラリをハンソンテーブルから自前のタイブルへ差し替える。 > • issue（タスク）は丸めず1単位ずつ細かく切って管理する。 > • 支援マスターのカウント項目を製品マスターへ移動し、画面上にも表示する（issue 0133）。 > • 承認フローは作成者と承認者を別にし、品管承認と現場責任者承認は順序性を持たせず並行で動かす。 > • 代理承認を可能にし、生産革新責任者ロールを複数名（4名程度）に付与して承認者不在でも運用が回るようにする。 > • 承認操作はログイン者の名前と日付を自動記録する。スーパー管理者には差し戻し権限を付与せず、承認履歴を消さない。 > • 製造指図の時間初期値を9時10分に設定する。 > • 製造指図画面でライン・人数を編集可能にする。 > • 管理番号は日付(YYMMDD)+連番でその日ユニークとする裁番ルールにする。並び替えで番号は変わらなくてよい。 > • > ロット単位で必要なキーは管理番号とは別名の新テーブル/キー（エクシーゲート連携用キー）として分離し、管理番号+ロット番号の組み合わせでユニークキーを作る。該当キーは印刷時に別紙で出す。 > ToDo > • [ ] DBに依存しない画面変更を自分のブランチ上で行い、PRを上げる（DBは直接いじらない） / 担当: 桃谷順天館 溝手章子様 > • [ ] Excel風編集ライブラリ（ハンソンテーブル）を自前のタイブルへ差し替える（製造指図書側の残り画面含む） / 担当: 櫻井文雄 > • [ ] 消された承認履歴の仕組みの原因を調査し復旧する / 担当: 櫻井文雄 > • [ ] 承認フロー（作成者≠承認者／品管・現場責任者承認の並行／代理承認）を実装する / 担当: 櫻井文雄 > • [ ] 生産革新責任者ロールに複数名（4名程度）を設定する / 担当: 桃谷順天館 溝手章子様 > • [ ] 支援マスターのカウント項目を製品マスターへ移動し、画面に表示する（0133） / 担当: 櫻井文雄 > • [ ] 製造指図の時間初期値を9時10分に設定する / 担当: 櫻井文雄 > • [ ] 製造指図画面のライン・人数を編集可能にする / 担当: 櫻井文雄 > • [ ] 管理番号の裁番ルール（日付+連番でその日ユニーク）を実装する / 担当: 櫻井文雄 > • [ ] ロット単位キー用の新テーブル/命名を設計し、エクシーゲート連携用のCSV出力（別紙印刷）を実装する / 担当: 櫻井文雄 > • [ ] ロット単位キーの名称を検討し、管理番号+ロットの組み合わせ運用を現場に説明・説得する / 担当: 桃谷順天館 溝手章子様 > > ---------------------------------------------- > 株式会社 AI-Path（アイパス） > 櫻井 美奈 > 東京都中央区銀座6-10-1 GinzaSix 13F > m-sakurai@ai-path.jp > -- ______________________________________________ 溝手 章子 e-mail ：a-mizote@e-cosmetics.co.jp URL :http://www.e-cosmetics.co.jp 株式会社 桃谷順天館 生産本部 岡山工場 生産技術 岡山県和気郡和気町米澤629-1 〒709-0515 TEL:0869-88-9000 FAX:0869-88-9020 ______________________________________________