SharePointで申請フォームを作る方法 標準フォームとPower Appsの使い分けを解説

備品の購入依頼、休暇の申請、社内問い合わせの受付。紙やExcelの申請書をメールでやり取りしていると、書式が古いまま提出される、誰が受け取ったのか分からない、集計するたびに手作業で転記する、といった問題が積み重なります。

SharePointを使えば、申請を受け付ける入力画面と、その内容を貯めるデータベースを同時に用意できます。しかも、多くの場合は追加の開発をせずに始められます。リストに列を定義するだけで、入力フォームは自動的に生成されるためです。

ただし、標準のままでは項目が縦に並ぶだけの画面になり、入力してもらうには物足りない場面も出てきます。本記事では、フォームを作る3つの方法とその使い分けから、リストの設計、カスタマイズの手順、そして運用でつまずく点までを順番に整理します。

確認したいポイント	結論	詳細
SharePointで申請フォームは作れる？	リストの標準フォームで作れる	列を定義すれば入力画面が自動生成され、追加の開発なしで申請を受け付けられます。
見た目や入力制御を変えたい	Power Appsでカスタマイズ	リストの「統合」からフォームのカスタマイズを選ぶと、条件付き表示や自動補完を設定できます。
社外から申請を受けたい	Microsoft Formsを使う	Formsで受け付け、Power AutomateでSharePointリストへ転記する構成が扱いやすくなります。
他人の申請を見せたくない	リスト分割や入力画面で制御	アイテム単位の権限設定はカスタムフォームと相性が悪く、構成そのものを見直すほうが安全です。

この記事でわかること

• 標準フォーム・Power Apps・Microsoft Formsという3つの方法とその選び方
• フォームの土台になるSharePointリストの列設計と入力制御の考え方
• 追加の開発なしで標準フォームに加えられるカスタマイズの範囲
• Power Appsでフォームをカスタマイズする手順と、権限まわりの注意点
• 「入力してほしい人に権限がない」など、運用で必ず出る課題への対処

▼ 社内の申請業務をどこまで効率化できるか整理したい方へ Microsoft 365や生成AIを使った業務効率化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

申請フォームを作る3つの方法

まず選択肢を把握します。SharePointで申請を受け付ける方法は大きく3つあり、必要な作り込みの量と、誰が入力できるかが異なります。ここを押さえないと、途中で作り直すことになります。

リストの標準フォームをそのまま使う

最も手軽なのが、SharePointリストに用意されている既定の入力画面です。リストに列を作れば、新規作成のボタンを押したときに表示されるフォームが自動的に生成されます。

設定作業はほぼ不要で、列の並び順や表示・非表示の調整も画面から行えます。項目数が10前後までの申請であれば、これだけで実用になります。

弱点は見た目の自由度です。項目が縦に並ぶだけの構成になるため、セクション分けや複雑な入力制御はできません。

Power Appsでフォームをカスタマイズする

2つ目が、リストのフォームをPower Appsで作り替える方法です。リストの「統合」メニューからフォームのカスタマイズを選ぶと、Power Apps Studioが開いて編集できます。

条件によって項目を出し分ける、特定の列を読み取り専用にする、入力内容から別の項目を自動で埋める、といった制御が可能になります。入力する側の負担を減らしたい申請ほど効果が大きくなります。

ただし、作り込むほど保守する人が必要になります。触れる人が社内にいるかどうかを確認してから採用してください。

Microsoft Formsで受け付けて転記する

3つ目が、Microsoft Formsで申請を受け付け、Power AutomateでSharePointリストへ転記する構成です。アンケート形式の画面が数分で作れ、URLを共有するだけで回答してもらえます。

最大の利点は、SharePointサイトへのアクセス権がない相手からも申請を受けられることです。社外の取引先や、別部署のメンバーから情報を集める場面で有効です。

一方で、入力された内容をそのままリストの列に対応させる処理が必要になります。入力項目が多い、あるいは頻繁に変わる申請では、この対応付けの保守が負担になります。

なお、3つを組み合わせることもできます。社外からの一次受付はForms、社内での補完入力はPower Appsのフォーム、といった使い分けは実際によく見られる構成です。

どれを選ぶかの判断基準

判断の軸は3つです。1つ目は入力する人の範囲で、社内の限られたメンバーなら標準フォームかPower Apps、権限のない相手が含まれるならFormsになります。

2つ目は入力制御の必要性です。項目の出し分けや値の自動補完が要るならPower Apps、単純な入力で足りるなら標準フォームで十分です。3つ目は保守できる人がいるか。作り込むほど、触れる人が限られていきます。

迷ったら、まず標準フォームで始めることをおすすめします。運用してみて足りない部分が見えてから作り込むほうが、無駄がありません。

フォームの土台になるリストを設計する

どの方法を選ぶにせよ、データを受け止めるリストの設計が出発点です。ここが雑だと、後から集計できない、修正が効かないという問題が出ます。

列の型を正しく決める

各項目に対して、1行テキスト、複数行テキスト、数値、日付と時刻、選択肢、ユーザーまたはグループ、はい／いいえといった型から適切なものを選びます。型を決めておくことが、入力の揺れを防ぐ最初の一手です。

金額や数量は数値型にします。テキスト型にすると、集計も大小での絞り込みもできなくなります。日付も同様で、テキストで持たせると期間での抽出が難しくなります。

申請者を記録する列は、既定で用意されている作成者を使えば足ります。同じ情報を別の列で二重に持たせると、どちらが正なのか分からなくなるため避けてください。

列名の付け方も最初に決めておいてください。後から表示名を変えても内部の名前は変わらないため、フローやフォームから参照するときに食い違いが生じます。運用を始める前に確定させておくのが安全です。

入力はできるだけ選択式にする

自由入力の欄が多いほど、表記の揺れが発生します。部署名、申請区分、勤務地のように値が決まっているものは選択肢列にしておくと、後の集計とビューでの絞り込みが安定します。

選択肢が頻繁に変わる、あるいは数が多い場合は、別のリストを作って参照列でつなぐ方法もあります。マスタ側を更新するだけで選択肢が変わるため、保守が楽になります。

必須と既定値を設定する

列の設定では、この情報を含める必要があるかどうかを指定できます。未入力のまま提出されると困る項目は、必ず必須にしておいてください。後から確認する手間が大きく減ります。

既定値の設定も有効です。申請日に今日の日付を初期表示する、区分に最も多い値を入れておく、といった工夫で入力の手数が減ります。

入力できる範囲を制限したい場合は、列の検証を使います。数値の上限下限や、開始日より終了日が後であることといったルールを設定でき、条件を満たさない場合はメッセージを表示できます。

ただし、検証の条件は列単位でしか書けないものと、リスト全体で書けるものがあります。複数の列にまたがる条件が必要な場合は、リストの設定側から指定してください。

添付ファイルの扱いを決める

見積書や写真を一緒に提出してもらう申請では、リストの添付ファイル機能を使うか、ドキュメントライブラリを別に用意するかを決めておきます。

添付ファイル機能は手軽ですが、ファイルに対して個別の管理はできません。ファイルそのものを検索したり、バージョン管理したりしたい場合は、ライブラリを使う構成のほうが適しています。

▼ 申請業務の設計からご相談いただけます どの業務から電子化すべきか、どこまで作り込むべきかは、業務の実態によって変わります。 現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

標準フォームでできるカスタマイズ

Power Appsを使わなくても、標準のフォームには実用的な調整の余地があります。まずはこの範囲で足りないかを確認してから、次の手段を検討してください。

列の表示と順序を整える

フォーム上でどの列を表示するか、どの順番で並べるかは画面から設定できます。システム的に必要でも入力してもらう必要がない列は、非表示にしておきます。

並び順は、実際に記入する流れに合わせます。紙の申請書があるなら、その項目順に合わせておくと現場の抵抗が小さくなります。

一覧側の表示も忘れずに整えておきます。申請を受け取る側が見るのはフォームではなくビューなので、必要な列だけを並べたビューを別に作っておくと、確認作業が短時間で済みます。

ヘッダーや本文に説明を追加する

フォームには、上部のヘッダー、入力欄の本文、下部のフッターにそれぞれ書式設定を加える機能があります。ここに記入方法の注意書きや、問い合わせ先を表示できます。

「提出前に上長へ口頭で確認してください」といった業務上の注意は、フォーム上に書いておくのが最も伝わります。マニュアルに書いても読まれません。

条件によって列を出し分ける

標準フォームでも、条件付きの数式を使って列の表示・非表示を切り替えることができます。区分が「その他」のときだけ詳細の入力欄を出す、といった制御が可能です。

設定は列の編集画面から行い、条件を数式として記述します。複雑な条件には向きませんが、単純な出し分けであればPower Appsを持ち出さずに対応できます。

フォームを共有して入力してもらう

SharePointリストには、入力用のフォームを作成して共有する機能もあります。回答者には一覧が見えず、入力画面だけが表示されるため、他人の申請を見せたくない場面で使えます。

ただし簡易的な入力フォームという位置づけで、Power Appsのような高度なカスタマイズはできません。用途を絞って使うのが前提になります。

Power Appsでフォームをカスタマイズする

標準フォームで足りなくなったら、Power Appsの出番です。リストのフォームだけを差し替える形なので、アプリを一から作るより手間はかかりません。

開き方と公開の手順

対象のリストを開き、コマンドバーの「統合」からPower Appsを選び、「フォームのカスタマイズ」をクリックします。Power Apps Studioが起動し、キャンバス上にフォームが読み込まれます。

編集が終わったら保存し、「SharePointに公開」を実行します。SharePoint側に反映されるのは最新の公開済みバージョンなので、保存だけでは反映されない点に注意してください。

公開後にリストの新規作成ボタンを押すと、カスタマイズしたフォームが表示されます。元の標準フォームに戻したい場合も、同じ統合メニューから切り替えられます。

編集画面では、既定で読み込まれているフォーム部品の項目を並べ替えたり、幅を変えたりできます。まずはこの範囲だけを触って公開してみると、反映の流れをつかめます。

カスタマイズでできること

Power Appsを使うと、条件付きで表示されるフィールド、読み取り専用のフィールド、入力値に応じた初期値の自動設定などが実現できます。公式のチュートリアルでも、これらを含むフォームの作り方が紹介されています（出典：Microsoft Learn「SharePoint リスト用のフォームをカスタマイズする」）。

入力欄をセクションに分けてタブのように切り替える、項目数の多い申請を複数ページに分けるといった構成も可能です。入力する人の負担を下げるという観点では、この自由度が大きな価値になります。

また、他のリストを参照して選択肢を作る、ユーザー情報から所属部署を自動で入れる、といった連携もできます。入力してもらう項目を減らすほど、申請の質は安定します。

権限まわりの注意点

見落とされやすいのが権限です。Power Appsでカスタマイズしたフォームは、手動で共有することができません。リストに対して読み取り以上のアクセス権を持つユーザーが、フォームへのアクセス権を自動的に引き継ぐ仕組みです。

さらに、リスト内の特定のアイテムに対する権限しか付与されていないユーザーは、カスタマイズされたフォームにアクセスできません（出典：Microsoft Learn「SharePoint フォームの統合について」）。アイテム単位で権限を細かく分ける設計とは相性が悪い、ということです。

「他人の申請を見せたくないからアイテムごとに権限を設定する」という発想は、この制限にぶつかります。権限の設計はフォームの作り方とセットで検討してください。

作り込みすぎない

Power Appsは自由度が高いぶん、作り込むほど保守できる人が限られます。数式が複雑になると、数か月後に自分でも読み解けなくなります。

最初は必要最小限の制御にとどめ、運用しながら足りない部分を追加していくほうが定着します。何をどう制御しているかを、簡単なメモとして残しておいてください。

▼ 「どこまで作り込むべきか」から相談できます 標準機能で足りるのか、Power Appsが必要か。 保守体制まで含めた判断も、実務目線でご相談いただけます。 ＞ 相談予約はこちら

Microsoft Formsを使う構成

入力する相手がSharePointにアクセスできない場合は、Microsoft Formsで受け付けてリストへ流し込む構成が有力です。仕組みと注意点を整理します。

向いている場面

最も適しているのは、社外からの申込みや、SharePointの権限を付与しにくい相手からの受付です。URLを共有するだけで回答してもらえるため、事前の準備がほとんど要りません。

組織内限定と、リンクを知っている全員という公開範囲を選べます。社外に出す場合は匿名回答になるため、誰が申請したかを記録したいなら氏名やメールアドレスの入力欄を設ける必要があります。

Power Automateでリストへ転記する

連携は、Formsの「新しい応答が送信されるとき」をトリガーにし、応答の詳細を取得してSharePointリストに項目を作成するという流れです。3つのアクションで基本形ができます。

注意点は型の変換です。Formsから返ってくる値は基本的に文字列なので、数値列や日付列へ渡す際には変換が必要になります。選択肢の値も、リスト側の選択肢と文字列が完全に一致していないと登録に失敗します。

添付ファイルを扱う場合は、ファイルアップロードの質問で受け取った内容をリストの添付ファイルへ移す処理が別途必要になります。ここは手間がかかるため、要件に含めるかどうかは慎重に判断してください。

連携がうまくいかないときは、まずテスト実行して応答の中身を確認してください。想像で数式を直すより、実際に返ってきている値を見てから組み立てるほうが確実です。

Formsを使うときの限界

Formsは初期設定では回答後の修正ができません。設定で回答者による回答の編集を許可すれば、フォームが回答を受け付けている間は直せますが、組織の管理設定によっては使えない場合があります。提出した内容を申請者が後から直す運用を想定するなら、この設定が使えるかを最初に確認しておいてください。

項目の出し分けは分岐機能である程度対応できますが、細かい入力制御や他システムの値を参照した自動補完はできません。これらが必要ならPower Appsを検討する段階です。

運用でつまずきやすい点

フォームが完成しても、実際に配布すると別の問題が出てきます。権限と、入力品質に関する課題が特に多く見られます。

入力してほしい人に権限がない

最も多いのがこれです。リストが置かれているサイトへのアクセス権がなければ、フォームは開けません。サイトの権限設計を確認せずにURLだけを配ると、問い合わせが殺到します。

対処としては、対象者をサイトのメンバーに追加する、申請用のサイトを分けて必要な人だけに権限を与える、あるいは前述のFormsを使う構成に切り替える、といった選択肢があります。

他人の申請が見えてしまう

リストの閲覧権限があると、既定では全員が全件を見られます。給与や評価に関わる申請では、この状態は許容できません。

アイテムごとの権限設定は、前述のとおりカスタムフォームとの相性が悪く、管理も複雑になります。リスト自体を分ける、あるいは申請専用の入力画面から登録させて一覧は見せないという構成のほうが現実的です。

リストの詳細設定には、ユーザーが自分で作成したアイテムだけを表示するという項目もあります。要件が単純であれば、この設定で足りる場合もあります。

入力ミスと表記の揺れ

自由入力が多いフォームでは、同じ内容が違う表記で登録されて集計できないという状態になります。選択肢列への置き換えと、列の検証による制限が基本の対策です。

それでも防げない誤りには、登録後のチェックで対応します。想定外の値が入ったときに通知するフローを用意しておけば、早い段階で修正できます。

あわせて、申請が正しく登録されたことを本人に伝える仕組みも用意しておいてください。送信後に何も起きないと、提出できたのか分からず二重に申請されることがあります。

スマートフォンからの利用

現場から申請する業務では、スマートフォンでの入力しやすさが定着を左右します。項目数が多いフォームは、小さな画面では一気に使いにくくなります。

入力してもらう項目を減らす、初期値で埋められるものは自動化する、写真の添付で済む部分は文章を求めないといった工夫が効きます。配布前に実機で試してみてください。

▼ 現場で使われるフォームづくりをご一緒に 権限設計、入力項目の絞り込み、承認への接続まで含めて、定着する形をご提案します。 導入前の検討段階でも構いません。 ＞ 相談予約はこちら

申請から先の流れまで設計する

フォームは入口にすぎません。受け付けた後にどう処理するかまで設計して、初めて業務が回ります。あわせて考えておきたい点を整理します。

承認プロセスへつなぐ

多くの申請には承認が伴います。Power Automateで、項目が作成されたときに承認依頼を送る構成にすれば、申請から承認までが一続きになります。

この場合、リストには承認ステータスや承認者、承認日時を保持する列が必要です。フォームの設計段階で、これらの列も含めて用意しておいてください。

差し戻しが発生する業務では、申請者が内容を修正できるかどうかも決めておきます。修正を許す場合は、いつの時点の内容だったのかを追えるようバージョン管理を有効にしておくと安心です。

ステータス管理と一覧の設計

申請者が自分の申請の状況を確認できるようにしておくと、問い合わせが減ります。ステータス列を用意し、自分の申請だけを表示するビューを作るのが基本形です。

管理する側にも、未処理のものだけを表示するビューを用意します。誰が見ても同じ基準で状況を把握できる状態にしておくことが、運用を安定させます。

紙の帳票をそのまま移さない

電子化でよくある失敗が、紙の申請書の項目をそのまますべて再現してしまうことです。押印欄や、実際には誰も見ていない記入欄が残っていないかを点検してください。

自動で分かる情報は入力させない、というのも重要な原則です。申請者名、所属、日付は、システム側で取得できます。入力項目を減らすほど、提出率は上がります。業務全体の見直し方は業務効率化アイデア55選の記事でも整理しています。

作った人に依存しない体制にする

内製した仕組みで最も多い失敗は、作成者の異動とともに誰も触れなくなることです。部署内に最低2人は中身が分かる人を置き、設計の意図をメモとして残すことが確実な対策になります。

どのリストのどの列を使っているか、カスタムフォームを使っているか、公開の手順はどうか。この3点を1枚にまとめておくだけで、引き継ぎの負担は下がります。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

SharePointで申請フォームを作る方法は、リストの標準フォーム、Power Appsでのカスタマイズ、Microsoft Formsからの転記の3つです。入力する人の範囲、必要な入力制御、保守できる人がいるかの3軸で選び分けます。

どの方法でも出発点はリストの設計です。列の型を正しく決め、値が決まっているものは選択肢にし、必須と既定値、列の検証を設定しておく。この準備が、後の集計と運用の質を決めます。

Power Appsでカスタマイズする場合は、権限の仕様に注意してください。フォームは手動で共有できず、リストのアクセス権を継承します。アイテム単位の権限しか持たないユーザーは、カスタムフォームを開けません。

そして、入力してもらう項目はできるだけ減らすこと。紙の帳票をそのまま移さず、自動で分かる情報は入力させない。承認やステータス管理まで含めて設計すれば、申請フォームは現場に定着します。

▼ 申請業務の電子化を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからフォーム・フローの設計、社内への定着支援までを一貫してご支援しています。何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら